| 00:27 | <zewt> | 2014, where it's a search engine hunt just to figure out how to fix the bug where firefox doesn't bother to ask where you want to download a file |
| 00:31 | <JonathanNeal> | Hello again. |
| 00:31 | <JonathanNeal> | Our family moved to Georgia over the weekend, and I had to stop work on the table sortable polyfill. Did someone else wrap it up or is it still needed? |
| 00:41 | <JonathanNeal> | Hixie_: is there a table sortable polyfill? |
| 01:00 | <caitp> | there was almost a real implementation, almost ;) but it was not to be |
| 01:02 | <Hixie_> | JonathanNeal: not to my knowledge |
| 01:02 | <JonathanNeal> | caitp: how so? |
| 01:02 | <Hixie_> | JonathanNeal: but there's plenty of sortable table scripts, which is what the spec was based on |
| 01:02 | <caitp> | blink folks didn't like the idea of making it a core platform feature |
| 01:03 | <caitp> | gecko is slightly further along (in that they've got microdata which is tangentially used by the sorting api), but they haven't really started it either and it's not clear if they'd want to |
| 01:04 | <caitp> | i guess you could always ask ms2ger or someone if they'd be willing to let you implement in gecko |
| 01:09 | <caitp> | without an intent for having core implementations, it's not clear that a polyfill is any more meaningful than another sorting library --- but I guess the world could always use another sorting library, for when they decide they didn't like the previous one |
| 01:11 | <JonathanNeal> | Yea, I made it almost as far as the complex magic that changes based on the kinds of elements you have, but Hixie gave me some great data to work with. If it’s okay for it to be public and there isn’t a test already, we should write a test. |
| 04:59 | <zcorpan> | annevk: i was checking if it would be trivial to fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=26121 but i don't know what to do |
| 07:31 | <boogyman> | zcorpan: how do you define "changes" in the context of that report? |
| 07:32 | <zcorpan> | boogyman: commits for https://github.com/ResponsiveImagesCG/picture-element/blob/gh-pages/source |
| 07:34 | <boogyman> | that appears as if it's documentation related to some specification, but not necessarily directly impacting the <picture> element (per se) |
| 07:54 | <annevk> | zcorpan: so web-apps-tracker has a local git checkout and does its comparisons on that |
| 07:54 | <zcorpan> | annevk: ok |
| 07:55 | <annevk> | zcorpan: most of that logic is at the end, at the start it's formatting functions |
| 08:44 | <annevk> | Domenic: second commit in that GitHub blog post is Servo implementing a recent change to DOM |
| 08:45 | <annevk> | W3C DOM was last updated mid-April, so much for keeping it up to date |
| 08:56 | <annevk> | JakeA: I guess I should make the change for .bodyUsed and .json() etc. right? |
| 08:56 | <annevk> | JakeA: nobody commented on the thread |
| 08:57 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/445 needs your review |
| 09:01 | <JakeA> | annevk: I'm happy with the .bodyUsed changes |
| 09:01 | <JakeA> | Will read that thread now |
| 09:01 | <JakeA> | The ticket I mean |
| 09:02 | <annevk> | Thanks. I'll look into obsoleting FetchBodyStream now then. Should have a bit of time today and during the weekend |
| 09:43 | <JakeA> | annevk: should we have response.xml() so we don't regress on XHR |
| 09:43 | <JakeA> | Or does no one care? |
| 09:43 | <JakeA> | I don't know if I care |
| 09:43 | <JakeA> | XML is dead to me |
| 09:44 | <jgraham> | heh |
| 09:46 | <annevk> | JakeA: no, that's a layering violation |
| 09:46 | <annevk> | JakeA: at some point we might want an async XML parser API that takes a response |
| 09:52 | <jgraham> | Or we might "put XML out to pasture" (i.e. shoot it in the head and boil it's carcasds to make glue)? |
| 09:52 | <jgraham> | *carcass |
| 09:55 | <Jirka_> | There are many APIs which provide only XML, not JSON. And JSON is not the best format for all use-cases. So droping XML seems silly. |
| 09:58 | <JakeA> | jgraham: I approve of the glue approach |
| 09:58 | <Ms2ger> | Why not lasagna? |
| 09:59 | <JakeA> | Jirka_: there'll always be https://developer.mozilla.org/en-US/docs/Web/API/DOMParser |
| 10:00 | <JakeA> | annevk: where's the violation (not disagreeing, just curious) |
| 10:00 | <annevk> | JakeA: making Fetch dependent on XML |
| 10:00 | <annevk> | JakeA: JSON is arguably on that line too, but since it's built into JavaScript... |
| 10:01 | <JakeA> | annevk: also formData & blob? |
| 10:01 | <annevk> | JakeA: see a thread about adding asHTML() or some such on WHATWG a while back |
| 10:01 | <annevk> | there's even a note under FetchBodyStream explaining this |
| 10:04 | <JakeA> | gotcha |
| 10:10 | <Jirka_> | I understand layering doubts, but if there is asJSON(), having asDocument() for HTML/XML would be very convenient |
| 10:12 | <annevk> | I'm not inclined to reopen http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jun/thread.html#msg72 |
| 10:17 | <annevk> | JakeA: should fetch() do anything in particular if it's passed a request whose bodyUsed returns true? |
| 10:18 | <JakeA> | annevk: should reject |
| 10:18 | <JakeA> | annevk: it needs to read the body & can't |
| 10:19 | <annevk> | I guess that's fair, the alternative was to just assume the body was empty |
| 10:19 | <annevk> | but rejecting makes it prolly clearer you want to clone your Request first or some such |
| 10:20 | <annevk> | oh right, .clone() |
| 10:20 | <annevk> | sadness |
| 10:20 | <annevk> | this is going to be quite a bit of work |
| 10:20 | <JakeA> | Yeah, I'd rather every method that needs to read body rejects if the bodyUsed is true |
| 10:21 | <annevk> | ooh :( |
| 10:21 | <annevk> | fetch() is defined as invoking Request's constructor |
| 10:22 | <Jirka_> | annevk: fair enough, I missed that thread |
| 10:22 | <JakeA> | annevk: yeah, imagine .clone is tough to define, although I think this stuff is *huge* for the platform |
| 10:22 | <annevk> | well it's a huge hack :p |
| 10:23 | <annevk> | clone() should be okay, defining fetch() with less trickery might be hard |
| 10:23 | <JakeA> | annevk: got https://jakearchibald.github.io/trained-to-thrill/ working offline yesterday & it felt like THE FUTURE |
| 10:23 | <JakeA> | (in Chrome Canary anyway) |
| 10:25 | <annevk> | JakeA: so... you used to be able to do new Request(request, dict) |
| 10:25 | <annevk> | JakeA: that was basically clone(), with restrictions so you can't end up with privileged Request objects |
| 10:26 | <annevk> | JakeA: maybe we should just keep that as a way of doing a tee? |
| 10:30 | <JakeA> | annevk: new Request(request, dict) - it feels like this would exhaust bodyUsed |
| 10:31 | <annevk> | that seems fine too |
| 10:31 | <annevk> | and throws if bodyUsed is set? |
| 10:31 | <JakeA> | I prefer .clone, but I can live with new Request(request, dict) as a way to clone |
| 10:31 | <JakeA> | yeah |
| 10:31 | <annevk> | ah okay, that actually makes this change easier :-) |
| 10:32 | <annevk> | we'll leave clone() distinct |
| 10:42 | <JakeA> | annevk: I get the feeling this is all coming together nicely. Some bikeshedding needed with the cache API todo, but it's really getting there. Who'd have thought it. |
| 10:46 | <JakeA> | annevk: if I respondWith an opaque response to XHR, XHR should onerror. How do you want to do this? Should XHR reject the response it gets back, or should it be a fetch flag such as "requires-untainted-response"? |
| 10:46 | <JakeA> | So fetch would send back a network error to XHR |
| 10:46 | <annevk> | JakeA: my idea was that we'd update all APIs to deal with the new response primitive |
| 10:47 | <annevk> | JakeA: implementations however might prefer that flag variety, but it doesn't seem as nice |
| 10:47 | <JakeA> | annevk: works for me. Will feed that back into https://code.google.com/p/chromium/issues/detail?id=411151 |
| 11:36 | <annevk> | JakeA: jgraham: https://github.com/whatwg/fetch/commit/a898f9a2941350aa625aa79b24673628ac2b2a8e |
| 11:38 | <jgraham> | annevk: Nice |
| 11:42 | <annevk> | I called it a mixin, anticipating a matching IDL change |
| 11:55 | <hsivonen> | I guess now it's my turn to extend the html5lib test format |
| 11:56 | <hsivonen> | proposal: the line following #document-fragment can be prefixed with "svg " or "math " to indicate the non-HTML namespace of the context node |
| 11:57 | <hsivonen> | using space instead of colon is consistent with the format for expected test output |
| 11:57 | <gsnedders> | hsivonen: I suggested that just after you went afk when you discussed this before :) |
| 11:57 | <gsnedders> | hsivonen: so +1 for that |
| 11:57 | <hsivonen> | and makes it possible to test names with colon |
| 11:57 | <hsivonen> | gsnedders: ok. thanks |
| 11:58 | <gsnedders> | (or rather I suggested using a colon and zcorpan pointed out that's not what the expected format was, but as mentioned that was me misremembering it rather than anything else) |
| 11:59 | <zcorpan> | hsivonen: lgtm |
| 12:01 | <hsivonen> | zcorpan: thanks |
| 12:02 | <zcorpan> | i think #document-fragment is a bit cryptic but i guess it would be work to change it and people don't care |
| 12:03 | <zcorpan> | #context-element would be clearer |
| 12:04 | <hsivonen> | zcorpan: I'd prefer to avoid the churn of changing it |
| 12:04 | <zcorpan> | yeah |
| 12:25 | <hsivonen> | so fragment parsing turns off the foreign lands breakout weirdness |
| 12:25 | <hsivonen> | but the <p><table> thing still varies by quirks mode in fragment parsing |
| 12:47 | <JakeA> | annevk: \o/ |
| 12:47 | <JakeA> | annevk: Regarding the XHR opaque response stuff, could you update the XHR spec? https://code.google.com/p/chromium/issues/detail?id=411151#c4 |
| 12:51 | <annevk> | JakeA: perhaps we should do this in Fetch... |
| 12:52 | <annevk> | JakeA: XMLHttpRequest's request mode is CORS or CORS-with-forced-preflight, so if the SW returns something that contradicts the mode, make it a network error |
| 12:53 | <annevk> | JakeA: respondWidth() could even error |
| 12:53 | <annevk> | respondWith() |
| 12:53 | <JakeA> | annevk: but a request to the same origin won't be CORS, it still needs to reject an opaque response |
| 12:54 | <annevk> | JakeA: mode is still CORS |
| 12:54 | <annevk> | JakeA: see http://fetch.spec.whatwg.org/#concept-request-mode |
| 12:54 | <annevk> | JakeA: only a couple of APIs actually use the same-origin mode |
| 12:55 | <JakeA> | annevk: ohhh! I thought a same-origin XHR would be no-cors |
| 12:55 | <JakeA> | if it's CORS, then I agree, we can handle it all in fetch |
| 12:55 | <annevk> | JakeA: no, <img> is no-cors |
| 12:55 | <annevk> | JakeA: document.load() is same-origin |
| 12:55 | <annevk> | JakeA: <img crossorigin> is CORS |
| 12:56 | <annevk> | JakeA: file a bug on Fetch I guess, not sure I can fix it today |
| 12:56 | <JakeA> | annevk: Cool. I'd had the same idea as you but thought it wouldn't work because of local requests. Doh. That makes things a lot easier then. |
| 12:56 | <annevk> | I have an enormous backlog and I'm not actually supposed to be working |
| 12:56 | <JakeA> | no worries, not urgent |
| 13:09 | <Ms2ger> | zcorpan, around? |
| 13:10 | <zcorpan> | Ms2ger: for a few more minutes yes |
| 13:10 | <Ms2ger> | When POSTing to a data url with XHR, what should .status return? |
| 13:10 | <Ms2ger> | Or annevk ^ |
| 13:12 | <zcorpan> | Ms2ger: dunno |
| 13:13 | <Ms2ger> | Alright, thanks |
| 13:24 | <Ms2ger> | (Figured it out) |
| 13:33 | <annevk> | Ms2ger: Fetch |
| 16:06 | <annevk> | jgraham+++++++ |
| 16:06 | <annevk> | that might not actually work |
| 16:06 | <annevk> | jgraham+=10 |
| 16:07 | <jgraham> | Heh |
| 16:07 | <jgraham> | I don't think the first one parses |
| 16:08 | <annevk> | I guess it's not the thought that counts when you hit a compiler error |
| 16:12 | <caitp> | would it be a bad thing to have a method of HTMLFormElement which assembles a FormData object automatically? that seems like a nice feature that people have already polyfilled a lot |
| 16:12 | <jgraham> | Certianly not from the point of view of the compiler :) |
| 16:12 | <caitp> | and pretty trivial to implement in a private script, for that matter |
| 16:13 | <jgraham> | caitp: Seems like a reasonable idea |
| 16:31 | <arunranga> | annevk, the underlying model of file reading now should be reusable by Fetch. The problems are in synchronous access in the API, but I think that’s a small difference; you should always use it asynchronously I think. |
| 16:33 | <arunranga> | Hixie_, there’s some ‘spec bugs’ to make ES’s function Realm reusable for script origin purposes. An example is: https://bugzilla.mozilla.org/show_bug.cgi?id=1058470 which refers to https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603 . |
| 16:40 | <annevk> | caitp: new FormData(<form>) does that |
| 16:53 | <caitp> | I suppose it does, but it doesn't do the rest of it |
| 16:54 | <caitp> | somehow things keep being done in weird ways in this platform rather than how you'd expect it to be done :) |
| 17:04 | <caitp> | like, suppose you wanted a list of VIN numbers parked in a given parking lot --- the `new FormData()` option is like going to the paper factory and asking them to create a set of papers containing vin numbers from <parking lot>, whereas my suggestion is more like asking the parking lot manager for a list of vin numbers in the lot |
| 17:04 | <caitp> | the first option is just totally backwards =) |
| 17:05 | <annevk> | no disagreement |
| 17:06 | <annevk> | I recommend reviewing APIs that are still in their infancy to make sure we don't make similar mistakes elsewhere |
| 17:11 | <smaug____> | hmm, which spec defines offsetTop these days? |
| 17:11 | <annevk> | smaug____: hasn't changed: http://dev.w3.org/csswg/cssom-view/ |
| 17:12 | <smaug____> | thanks |
| 17:34 | <erlehmann> | Hixie_ i have done an art (is there prior art?) http://news.dieweltistgarnichtso.net/bin/mimesniff.html |
| 17:34 | <erlehmann> | i need some algorithm to perform the pattern mask stuff in shell |
| 17:34 | <erlehmann> | have not figured that out |
| 17:34 | <erlehmann> | JonathanNeal how is your table sort going? |
| 17:41 | <Hixie_> | erlehmann: ? |
| 17:41 | <erlehmann> | Hixie_ i have started implementing the mime sniffing in bourne shell. |
| 17:41 | <erlehmann> | are you aware of any other implementations? |
| 17:42 | <Hixie_> | i but what why why would you do that in a shell |
| 17:42 | <Hixie_> | browsers all implement some variant of that spec |
| 17:42 | <Hixie_> | but dunno how closely |
| 17:42 | <erlehmann> | my blog software, hipster news, is a shell script. its only dependency is busybox or coreutils |
| 17:42 | <erlehmann> | and file(1) is not among busybox |
| 17:43 | <erlehmann> | i thought it would be a good thing if i had a command line tool that matches what browser think |
| 17:43 | <Hixie_> | you wrote web-facing software using a shell script? |
| 17:43 | <Hixie_> | oh man, that's a security nightmare waiting to happen |
| 17:43 | <erlehmann> | Hixie_ it is a *static site generator* |
| 17:43 | <Hixie_> | that amost beats the guy i know who wrote a functioning vt100 emulator in bash script |
| 17:44 | <Hixie_> | oh, static |
| 17:44 | <Hixie_> | ok |
| 17:44 | <erlehmann> | it is invoked from a git hook. |
| 17:44 | <Hixie_> | that's still crazy but far less so |
| 17:44 | <erlehmann> | http://news.dieweltistgarnichtso.net is regenerated every time i git push to one of its repositories |
| 17:44 | <erlehmann> | most files are html or plain text |
| 17:45 | <erlehmann> | but i am working on media support, so i can just throw binaries in there and make it do *the right thing* |
| 17:46 | <erlehmann> | whole blog software is 250 LOC and i aim for less. |
| 17:46 | <JonathanNeal> | erlehmann: haven’t worked on it since moving to Georgia! |
| 17:47 | <JonathanNeal> | But I got a chance to pull the project to my wife’s laptop last night, so now I can continue. I just wasted my time in specification, too, so I’m definitely ready to tinker. http://discourse.specifiction.org/t/extending-classlist-methods-to-allow-regexp/585/5 |
| 17:47 | <erlehmann> | Hixie_ people build static site generators in less than 100 LOC http://wcm1.web.rice.edu/colophon.html |
| 17:47 | <erlehmann> | the most complexity with mine is figuring out how to manage atom ids |
| 17:48 | <JonathanNeal> | I love specification, even though it’s way more dead now. I wish I could get paid just to play there. |
| 17:48 | <erlehmann> | i even have XSLT that creates HTML out of feed :3 http://news.dieweltistgarnichtso.net/bin.atom |
| 17:48 | <erlehmann> | but i have to go! |
| 17:51 | <Hixie_> | all the sites i write these days are just static data that communicates over websocket to a server somewhere |
| 17:52 | <Hixie_> | no static code generation, just static code :-) |
| 19:57 | <annevk> | https://twitter.com/dalecruse/status/507950215702511616 |
| 20:00 | <miketaylr> | lol |
| 20:04 | <jgraham> | hahahaha |
| 20:05 | <jgraham> | It's like kids say the most embarassing things, but not kids |
| 20:14 | <Sample> | This w3c and whatwg civil war is crazy |
| 20:14 | <Sample> | this seems to have the ease of resolution as a religious conflict |
| 20:15 | <Hixie_> | there's not really a civil war |
| 20:15 | <Hixie_> | there's a bunch of people doing good work at both the w3c and whatwg |
| 20:15 | <Hixie_> | and then there's a small number of people at the w3c, copying the work from those at the whatwg, and publishing it at the w3c. |
| 20:15 | <Hixie_> | and a small number of people at the whatwg who are frustrated by this and asking for them to stop |
| 20:15 | <Hixie_> | that's pretty much it |
| 20:20 | <Sample> | okay, so long as the people who direct the small number of w3c people are in agreement with whatwg this sounds pretty non-problematic/resolveable |
| 20:20 | <Hixie_> | there are no people who direct the small number of w3c people in question |
| 20:20 | <Hixie_> | it's, like, the w3c ceo |
| 20:21 | <Sample> | that's an unusual hierarchy |
| 20:21 | <Hixie_> | what is? |
| 20:21 | <Sample> | employees of an organization with no organization |
| 20:22 | <Sample> | they just do whatever they please? |
| 20:23 | <caitp> | the political landscape of the web is probably too complicated to really accurately draw up in an irc conversation |
| 20:23 | <caitp> | or book |
| 20:27 | <Sample> | do members/employees of these organizations all work remotely? I presume there isn't a physical headquarters where everyone sits together in a cubicle all day |
| 20:29 | <Hixie_> | i'm confused |
| 20:29 | <Hixie_> | the w3c is a pretty normal organisation as far as this goes |
| 20:29 | <Hixie_> | they have a CEO and people who work for the CEO, and there's also people for other companies who work with them |
| 20:29 | <Hixie_> | those are the people who do the aforementioned copying |
| 20:30 | <Hixie_> | the WHATWG isn't an organisation in the same sense, it's just a bunch of people, most of which work for various companies, who work on specs in a common venue |
| 20:31 | <Hixie_> | these people all work On The Internet, some in similar locations as others, but spread all over the world |
| 20:31 | <Hixie_> | (except africa, mostly) |
| 20:31 | <Hixie_> | (and very few in south america) |
| 20:51 | <Sample> | btw someone should submit <something>/form-data to the IANA to at least allow people to start choosing to out out or migrate away from the specification breaking x- prefixed and overly verbose application/x-www-form-urlencoded that I suppose Tim Berners-Lee is responsible for |
| 20:51 | <Sample> | opt out* |
| 21:17 | <hober> | Sample: application/x-www-form-urlencoded is here to stay. why do you think we can move away from it? |
| 21:22 | <caitp> | speaking of things which are a bit underspecified, wouldn't it be great if the interpretation and serialization of query parameters were stronger --- or rather, if it existed at all? I mean sure a lot of webservers would do the wrong thing, but it would be just beautiful if there were an expected behaviour other than "make it work the way jquery does it" |
| 21:23 | <caitp> | heck, would make things easier for URLUtils too |
| 21:30 | <Sample> | hober: I do think we can, yes. the burdeon would only lie on those whose primary job is to ensure their webservers are standards compliant |
| 21:31 | <caitp> | deprecating things is hard :( |
| 21:31 | <caitp> | removing things is even harder :( it would be lovely if it were easier |
| 21:34 | <Hixie_> | Sample: just imagine "x-" means "excellent-" instead of "experimental-" |
| 21:34 | <Sample> | x-www will never be removed but we can enable application developers to move away from it |
| 21:34 | <Sample> | lol |
| 21:39 | <hober> | why? what would moving away from it get them? |
| 21:39 | <caitp> | but in practice, clients aren't going to start sending whatever-new-mimetype unless servers understanding it, and servers aren't likely to start understanding whatever-new-mimetype unless clients send it |
| 21:39 | <Sample> | hober: standard compliance with the MIME spec? sanity? |
| 21:40 | <hober> | how is application/x-www-form-urlencoded not sane? |
| 21:40 | <Sample> | rehtorical question |
| 21:42 | <caitp> | you could also reframe http://xkcd.com/927/ to apply to this, for better or worse |
| 21:43 | <caitp> | if you were to consider a specific mimetype to be a "standard" |
| 21:45 | <Sample> | caitp is at least making a point. and that's totally true and understood. but if "Server X" values standards and does the likely simple implementation of understanding the new mime type in the same manner it understands the original, what's the loss |
| 21:46 | <Sample> | additionally those who write backends can now in a compliant manner opt to use something that seems less totally antiquated/accidental/incidental |
| 21:47 | <hober> | the loss is the engineering required to implement/test/etc a redundant value. |
| 21:48 | <Sample> | I'm not suggesting anything backwards incompatible. it's the same premise as a company developing an internal tool and using API's that don't exist in IE9, they are targeting towards modern implementation |
| 21:48 | <hober> | would this new media type actually do anything different than the one we already have? if not, there is no reason to mint it |
| 21:48 | <Sample> | it would absolutely not |
| 21:48 | <caitp> | the point being made is that it's pretty cosmetic |
| 21:48 | <Sample> | or that it offers the use of something compliant with the MIME spec |
| 21:49 | <Sample> | with extraordinary little overhead |
| 21:49 | <Sample> | purely opt-in |
| 21:50 | <hober> | i must be missing something |
| 21:50 | <Sample> | it's slightly odd to me that this is an issue of "good enough" |
| 21:51 | <Hixie_> | Sample: standard compliance with the MIME spec is not a goal in and of itself. Standards compliance is a tool, the goal being interoperability. We have interoperability here (quite a lot of it, considering). |
| 21:51 | <Hixie_> | Sample: also, re sanity... see /topic |
| 21:52 | <Sample> | we don't need an actual IANA approved and spec compliant mime type for this because what we have is "not bad enough". if it were x-IlllIlIlIl it would cross the threshold of "bad enough" |
| 21:53 | <caitp> | if anyone had the chance and ability to do so without negative consequence, they'd throw away the status quo and replace it with something that was well-designed and built to last, where nothing ever needed to be thrown away or replaced |
| 21:53 | <Hixie_> | it could x-\0\0\0 and be "good enough" -- the criteria isn't based on what hte name looks like, it's based on how interoperable it is. |
| 21:56 | <Sample> | I may totally be off basis and I value your guys judgements immensely. It is polish, I agree. But I don't think that righting this wrong is any more abusive than creating new APIs. They exist for a better future. In this case, it would be trivial to support |
| 21:57 | <hober> | synonyms are not zero-cost |
| 21:57 | <Sample> | I agree |
| 21:58 | <Hixie_> | Sample: why is it a "wrong" |
| 21:58 | <Sample> | if no single web server implementer chose to support it it wouldn't matter |
| 21:58 | <caitp> | wouldn't it though? if clients were sending it? |
| 21:58 | <Sample> | Hixie_: the x- prefix |
| 21:59 | <Hixie_> | Sample: Why is the x- prefix wrong? |
| 22:00 | <Sample> | Hixie_: it carries the implication it's not a standard type |
| 22:00 | <Hixie_> | Sample: why is the implication that it's not a standard type a bad thing? |
| 22:01 | <Sample> | because it clearly is. there is a standard to that type. it should be recorded through IANA and documented as such |
| 22:01 | <Sample> | I didn't make up these rules =P |
| 22:01 | <caitp> | but it's cosmetic because people treat it as a standard type |
| 22:01 | <Hixie_> | Sample: it's not clearly a bad thing. You think it's a bad thing. Others don't. Hence my question: why do you think it's a bad thing that there is an implication that this standard type is not in fact a standard type? |
| 22:03 | <Hixie_> | caitp: it _is_ a standard type. It's specced at http://www.whatwg.org/specs/web-apps/current-work/#application/x-www-form-urlencoded and was sent to the ietf/iana in http://www.ietf.org/mail-archive/web/ietf-types/current/msg01711.html and is listed in http://www.iana.org/assignments/media-types/media-types.xhtml |
| 22:04 | <caitp> | yes, in spite of the implication |
| 22:04 | <caitp> | that is what I'm saying |
| 22:04 | <caitp> | although picking through the ietf cardboard boxes to find evidence of it, yikes :p |
| 22:08 | <Sample> | oh that's interesting, I didn't realize they accepted it as a standard and kept the prefix |
| 22:08 | <Hixie_> | (even if they hadn't it would change nothing to my argument) |
| 22:08 | <Hixie_> | my point is that standards don't matter |
| 22:09 | <Hixie_> | interoperability is what matters |
| 22:09 | <Hixie_> | standards are nothing but a tool to help that along |
| 22:09 | <Hixie_> | if we have interoperability, then the job of the standards is done |
| 22:09 | <Hixie_> | and any additional change could only lead us away from interoperability, which is a bad thing |
| 22:10 | <Sample> | I suppose Chrome could start only sending application/form-data headers on form submissions which only "Google Web Server" would accept but... seems rather far fetched =D |
| 22:11 | <caitp> | which brings up the point I mentioned earlier, why can't we have specific rules for serialization and interpretation of search queries in urls, because there are so many inconsistent and non-interoperable ways to do it ;-; |
| 22:11 | <caitp> | sigh, websites >:( |
| 22:12 | <Sample> | I write code that IE9 never knew about. Hell I can choose to write code that IE10 should have but didn't implement because it's more elegant. I should also be able to write a server knowing exactly what application will send to it that accepts a non RFC contradicting beautiful mime type |
| 22:12 | <Sample> | just my two cents. I realize that there is some seriously vehiment opposition to the notion |
| 22:12 | <caitp> | nah, tbh it's a friday afternoon, it's hard to be particularly vehement about anything |
| 22:13 | <caitp> | heck, still procrastinating on preparing for my conference talk in 2 weeks |
| 22:14 | <Sample> | hober will die on his sword before the day he seems a mime type that conforms to RFC 1521 as an alternative to the incidental original =P |
| 22:14 | <Sample> | sees* |
| 22:14 | <Hixie_> | Sample: i'm just trying to understand why you think it's a bad thing that there is an implication that this standard type is not in fact a standard type |
| 22:14 | <Sample> | Hixie_: bad is totally subjective. I'm trying to simply say that having a standard prefixed with an x- violates RFC 1521 |
| 22:15 | <Sample> | that's my only argument |
| 22:15 | <Hixie_> | Sample: ok. Why is having a type that violates RFC 1521 a "wrong" that needs to be righted? |
| 22:17 | <caitp> | > to indicate its non-standard status and to avoid a |
| 22:17 | <caitp> | potential conflict with a future official name. --- maybe they should replace "indicate" with "connotate" |
| 22:17 | <caitp> | that would make everything better |
| 22:18 | <hober> | Sample: I will? Why does everyone always refer to my death in standards discussions? |
| 22:18 | <hober> | ( this actually has happened more than once. e.g. http://lists.w3.org/Archives/Public/public-html-admin/2014Feb/0062.html ) |
| 22:19 | <hober> | I think the conclusion here is that 1521bis should allow application/x-www-form-urlencoded since it is interoperable. |
| 22:20 | <Hixie_> | the existence of that entire thread is such a sad reflection of humanity |
| 22:20 | <Sample> | lol |
| 22:21 | Sample | looks suspiciously at Hixie_'s trick question =P |
| 22:21 | <Sample> | did you ask why is violating the RFC considered a wrong that needs to be righted? |
| 22:21 | <Hixie_> | yes |
| 22:21 | <Sample> | it's like the philosophical dicussion of why is murder considered bad |
| 22:22 | <jgraham> | … |
| 22:22 | <caitp> | *headscratch* |
| 22:22 | <Hixie_> | Sample: this implies that for you, standards-compliance is a goal in and of itself, with no ulterior motive. is that right? |
| 22:23 | <Sample> | bad is a violation of the law? |
| 22:24 | <Sample> | I get what you're saying though. The fact that it works supercedes the fact that it violates RFC |
| 22:24 | <Hixie_> | personally i'm saying the fact that it violates the RFC is literally of no consequence whatsoever. |
| 22:24 | <Sample> | Non-conformance with specs is totally okay |
| 22:24 | <hober> | it's only evidence that the rfc should be updated to reflect interoperable reality |
| 22:25 | <Hixie_> | sample: imho, conformance with specs is not a goal. |
| 22:25 | <hober> | specs that don't reflect reality are the most boring form of science fiction |
| 22:25 | <jgraham> | hober++ :) |
| 22:25 | <Sample> | that's cute =P |
| 22:25 | <jgraham> | Sample: hober is quoting something Hixie said some years ago I believe :) |
| 22:26 | <Hixie_> | i wish it had convinced more than like the four of you who hang out here regularly. :-P |
| 22:26 | <Sample> | I guess all I'm left ot wonder is how would adding a mime type which is both (subjectively) more sane and actually abides by the RFC going to cause a pandemic of interoperability |
| 22:26 | <Hixie_> | Sample: it isn't. It will cause no benefit and minimal harm. |
| 22:26 | <Hixie_> | Sample: but no benefit and minimal harm is still a net harm. |
| 22:27 | <Hixie_> | see also http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 |
| 22:27 | <caitp> | unless nobody ever implemented it |
| 22:27 | <Hixie_> | Sample: to put it another way. There's two ways we could fix this. We could add a new type, which requires changing a spec and multiple implementations, or, we could change the one spec that says x- is bad, which would require nothing but changing that spec. |
| 22:28 | <Hixie_> | Sample: how do you determine which of these options is the better option? |
| 22:28 | <jgraham> | Well if no one ever implements something, someone wastes some time trying to specify it. Which could be a useful educational exercise. People possibly also waste some time deciding to not implement it, which probably isn't |
| 22:28 | <Sample> | Hixie_: adding a new type would NOT require ANY implementations |
| 22:28 | <Sample> | it is simly an allowance |
| 22:29 | <Sample> | and you cannot change x- without causing serious problems to everyone who uses the header as intended |
| 22:29 | <caitp> | but if nobody was going to implement it, what would be the point in specifying it |
| 22:29 | <Hixie_> | Sample: i'm not sure i understand your proposal exactly. Can you elaborate? |
| 22:31 | <Sample> | leave the glaring problem. leave the RFC as-is. admit the misake and the (necessary) violation. add application/form-data which is a content type with a standard expectation (defined in the HTML specification) |
| 22:32 | <Hixie_> | anyone know anything about the interaction of Exposed and Global in WebIDL? Do I really need to say Global=Foo,Exposed=Foo? Or does Global=Foo imply Exposed=Foo? |
| 22:32 | <Sample> | and we've given birth allowance |
| 22:32 | <Hixie_> | i can't tell from reading the webidl spec |
| 22:32 | <Hixie_> | Sample: when you say |
| 22:32 | <Hixie_> | uh |
| 22:32 | <Sample> | to* allowance |
| 22:32 | <Hixie_> | Sample: when you say "with a standard expectation", what is that expectation? like, what would it mean for someone to use this type? where would we see it? |
| 22:33 | <Sample> | in the same way that the ever evolving ECMAScript specification does. it allows you to use something more elegant, to fix mistakes, but it isn't necessary. and you must known your target |
| 22:33 | <Hixie_> | no i mean concretely |
| 22:33 | <Hixie_> | where would it be used? |
| 22:33 | <Sample> | if I use something new I must have a reasonable expectation that I know exactly what client will be consuming my work |
| 22:33 | <Hixie_> | is this a type a server sends to another server? a browser posts to a server? what? |
| 22:34 | <Sample> | Hixie_: it doesnt matter |
| 22:35 | <caitp> | doesn't heycam sit in here? |
| 22:35 | <Hixie_> | Sample: well if you want me to spec something it kinda matters that i know what you want me to spec |
| 22:35 | <caitp> | might be a good person to ask re: webidl confusion |
| 22:35 | <Sample> | Hixie_: the standard expectation for application/form-data is the expectation of how the data will arive/can be parsed, as defined in the HTML specification |
| 22:36 | <Sample> | it doesn't matter how you use the content type, it's just a content type |
| 22:36 | <Sample> | there is no requirement "this must only be used by proxies" |
| 22:36 | <Sample> | or some such |
| 22:36 | <Hixie_> | Sample: it matters if it's a type that browsers are required to send or a type that servers are allowed to send |
| 22:37 | <Hixie_> | Sample: because if it's a type that browsers are required to send, then it's a non-backwards-compatible breaking change |
| 22:37 | <Sample> | does any mime type demand it's requirement? it's just a suggestion of how to understand the payload |
| 22:38 | <Sample> | there is of course absolutely no requirement the browers send it |
| 22:38 | <Hixie_> | well for example the x-www mime type we were talking about earlier is the type we require that browsers send when you do a form submission |
| 22:38 | <Sample> | it would be a terribly bad idea for them, I think the browser would immediately significant popularity =P |
| 22:39 | <Sample> | Hixie_: is it really mandated somehow? or is it a suggestion for how to encode data |
| 22:39 | <Hixie_> | so if we're trying to provide a new type for x-www-..., and we require that browsers keep using the old x-www-... type, then the entire exercise is rather pointless |
| 22:39 | <Hixie_> | it is what the HTML spec requires |
| 22:39 | <Hixie_> | but more importantly |
| 22:39 | <Hixie_> | it's what's needed for interoperability |
| 22:41 | <Sample> | no I'm definitely not suggesting we're trying to do-away with the x-www |
| 22:42 | <Sample> | as I said leave the glaring problem. leave the RFC as-is. admit the misake and the (necessary) violation. add application/form-data which is a content type with a standard expectation (defined in the HTML specification) |
| 22:42 | <Hixie_> | so what are you suggesting? we introduce a new type that does nothing useful? (as in, since browsers never send it, and nobody else ever has a reason to send it?) |
| 22:43 | <Sample> | I would rephrase that to say, that does nothing new, yes |
| 22:43 | <Hixie_> | ok so what is the value here? |
| 22:43 | <Sample> | what is the value to being able to forEach a NodeList? old code doesn't need it |
| 22:44 | <Hixie_> | i don't know. I'm not proposing that we be able to forEach a NodeList. |
| 22:44 | <Sample> | it's an allowance |
| 22:44 | <Hixie_> | an allowance to whom? we've just established that we're _not_ going to allow browsers to send it. |
| 22:44 | <caitp> | that has been proposed though (making HTML collections inherit from Array) |
| 22:44 | <Sample> | and I can decide to do something more properly or more elegantly. oops, we made a mistake. instead of forcing that upon you, here's an alternative. langauges do it all the time |
| 22:44 | <Hixie_> | there's nobody else who ever needs to send this type. |
| 22:44 | <Hixie_> | but you said we _should_ keep forcing the old type on browsers |
| 22:45 | <Hixie_> | i'm not understanding who this is an allowance for. |
| 22:45 | <Sample> | programmatic form submission |
| 22:45 | <Sample> | I'm obviously not talking about what the web browsers do |
| 22:46 | <caitp> | but if servers don't understand application/form-data, then the browser would have to translate it before sending |
| 22:46 | <Sample> | browsers use content types too, yes |
| 22:46 | <caitp> | and i'm not sure that would go over very well |
| 22:46 | <Sample> | caitp: I'm not suggesting browsers send anything but x-www (for a long while) |
| 22:47 | <Hixie_> | wait you want this type just so that one server can talk to another server? nothing to do with browsers? |
| 22:47 | <caitp> | you're saying "let people specify it programmatically" :z |
| 22:47 | <caitp> | which means that someone would have to translate it back in order to ensure that it's understood |
| 22:47 | <Sample> | yes, browsers use Content types, that's completely irrelevant to my discussion =P |
| 22:47 | <Sample> | they are ONE of the things that use content types |
| 22:47 | <Hixie_> | if you just want a new type for server-to-server communication, then (a) just go ahead and use the type, nobody else will be affected, and (b) if you want to register it, go ahead, nobody else will be affected :-) |
| 22:48 | <Sample> | lol okay |
| 22:49 | <Sample> | I forsee a world where we all rejoice knowing that we've enabled a more beautiful future some fine day, far, far away =P |
| 22:49 | <caitp> | that's what they said when they invented top 40 radio, and look how that turned out |
| 22:49 | <Sample> | whatwg doesn't think only through the lens of a web browser do they? =P |
| 22:49 | <Sample> | especially when it breaks nothig a web browser does |
| 22:50 | <caitp> | well there's a distinction between the internet and the world wide web, I guess |
| 22:51 | <Hixie_> | Sample: having two types to do the same thing is not more beautiful than having one, imho :-) |
| 22:51 | <caitp> | but what if it were a rainbow of seven types |
| 22:51 | <caitp> | positioned in an aesthetically pleasing manner |
| 22:52 | <jgraham> | Plus you never actually reach the beautiful future because more cruft accumulates as you try to get there |
| 22:53 | <hober> | if you won't believe us, believe this season's doctor who opener. there is no promised land. |
| 22:54 | <Sample> | I think enabling a compliant choice of beauty outside the realm of the browser is better than a mandate of (what is liekly subjectively agree'd upon) ugly |
| 22:55 | <Sample> | hey guys I can't save the world but I can pick up some litter and hope that we at least do that much in the face of a chaotic world =P |
| 22:55 | <hober> | i don't think that analogy works. a better analogy is that minting a redunant type is littering |
| 22:56 | <hober> | something something occam |
| 22:56 | <Sample> | see my last comment for a response =P |
| 22:56 | <Sample> | err second to last, now 3rd |
| 22:56 | <caitp> | https://petitions.whitehouse.gov/petition/create surely if obama says to do it, everyone will have to do it |
| 22:56 | <jgraham> | Even if you think this is a real improvement, it seems hard to justify putting any effort at all into fixing it giving how many more serious issues there are for the internet in general and the web in particular |
| 22:56 | <Sample> | jgraham: that's my point, like Hixie said, there isn't any effort involved. I should just submit it to IANA (somehow) |
| 22:56 | <caitp> | (how is the webmata petition coming? that was an amusing one) |
| 22:57 | <jgraham> | Well the oppertunity cost of this conversation is non-zero |
| 22:57 | <Sample> | jgraham: agreed! feel free to move onto more important matter at any time =) |
| 22:58 | <Sample> | i was just curious to poll you guys on this topic |
| 22:58 | <caitp> | https://petitions.whitehouse.gov/petition/help-fund-new-w3c-distributed-web-webmata-wwwwebmataorg/P0THLXWH still sitting at just one signature, aww |
| 22:58 | <Sample> | my other form suggestions went over very well =P |
| 22:59 | tantek | perks up at "distributed web" |
| 22:59 | tantek | notes http://www.webmata.org/ …. is a PDF. #dogfoodfail |
| 22:59 | <caitp> | I'm pretty sure it was created as a joke |
| 22:59 | <caitp> | because the authors signature is just too suspect |
| 23:00 | <tantek> | "Furry Baby Boo" ? |
| 23:00 | <tantek> | perhaps this is one of those machine-generated papers |
| 23:01 | <tantek> | where's the button to "Report Petition as fake" ? |
| 23:02 | <caitp> | do they have one? i'm not sure anyone at the whitehouse actually moderates or reads the petition site at all |
| 23:02 | <caitp> | or in DC, or in the country |
| 23:26 | <TabAtkins> | Oh, wow. That webmata thing... It's like a Markov Babbler, but just sensical enough to have clearly been written by a real person. |
| 23:26 | <TabAtkins> | It trips all of my "schizophrenic crackpot" alarms, though. |
| 23:53 | <TabAtkins> | Domenic: Inline biblio works now. Just add a <pre class=biblio>, containing JSON in the SpecRef format. |