| 00:06 | <Hixie> | annevk: planning on doing registry stuff in january |
| 00:06 | <Hixie> | nessy: yt? |
| 00:08 | <Hixie> | nm, gotta go |
| 00:08 | <Hixie> | bbl |
| 04:08 | <roc> | this morning my 8-year-old son asked me what's the difference between XHTML and HTML, and why don't people use XHTML |
| 04:09 | <roc> | Someone needs to write a book of Web standards fairy-tales for children |
| 04:25 | <tantek> | roc, that's awesome. |
| 04:26 | <tantek> | feel free to childrens-bookize this blog post: http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5 |
| 04:29 | <MikeSmith> | roc: if he starts asking about http-range-14, that'd be a time to worry |
| 08:34 | <odinho> | nessy: We had a discussion on TPAC about the TR page. The room agreed that the WG should be allowed to put whatever there. |
| 08:34 | <odinho> | nessy: So, e.g. for IndexedDB the last year, that would be its editors draft. Because reading the WD version was utterly bogus (lots of old stuff) |
| 08:35 | <odinho> | Also, as I said yesterday, I coded directly to spec, and ended up having to patch in order for it to work in contemporary Chrome and IE. -- So that caniuse-integration, and hopefully at attribute-method level would be very useful for webdevs. |
| 08:36 | <odinho> | I guess that's why webdevs doesn't really use the spec. I had to do extra work in the end because of it :P |
| 08:37 | <odinho> | (Well, worked in Opera, -- but guess that's because we updated dom level 3 events not too long ago. |
| 09:23 | <zcorpan> | wow i didn't know Hixie used an *SVG* repository to edit the spec. https://github.com/w3c/html#how-the-branches-fit-together |
| 09:26 | <hsivonen> | why isn’t that chart itself SVG? |
| 10:06 | <Stevef> | tabatkins: was concerned by your statement http://krijnhoetmer.nl/irc-logs/whatwg/20121201#l-144 so have asked HTML WG chairs if it is correct http://lists.w3.org/Archives/Public/www-archive/2012Dec/0002.html |
| 10:07 | <hsivonen> | Stevef: hi. does http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/ contain your latest findings on role=main usage? |
| 10:08 | <hsivonen> | or is there something more recent I should be reading? |
| 10:08 | <Stevef> | tabatkins: I am on one of the lists as edit a few specs in the html wg, I have not noticed any decisions on that list other than administrative ones |
| 10:08 | <Stevef> | hsivonen: no thats the latest |
| 10:08 | <hsivonen> | I was not aware of those treehouse lists before the meme |
| 10:08 | <hsivonen> | Stevef: thanks |
| 10:09 | <annevk> | Stevef: the real context is http://krijnhoetmer.nl/irc-logs/whatwg/20121130#l-1012 |
| 10:10 | <annevk> | zcorpan: SVG can do anything |
| 10:10 | <annevk> | odinho: dude, mention the feature |
| 10:12 | <zcorpan> | i'm on one of the lists too but didn't reflect over its secretness |
| 10:13 | <Stevef> | annevk: OK, well that statement is similar, I thought that the way it worked is/was editors are free to make changes to the specs that are interop bug related or editorial. and the wg is notified of these, anything controversial such as addition of new features or significant chnages to current spec are documented by the editors and not added until wg has agreed. |
| 10:15 | <Stevef> | but I could be wrong... |
| 10:15 | <annevk> | Stevef: if you don't think there's a lot of private stuff going on around the HTML WG and lobbying and such you're unfortunately misled; fortunately none of it seems to have much of an effect in practice though |
| 10:15 | <annevk> | or fortunately, I don't really care anymore what they're up to |
| 10:16 | <Stevef> | annevk: what i recently have realised in the last week is there is a lot of private stuff going on in HTML standardization full stop |
| 10:16 | <annevk> | well I do, but I've given up |
| 10:17 | <Stevef> | and I don't think that the HTML WG is any more or less prone to it |
| 10:18 | <odinho> | annevk: OH THE SUSPENSE. I was actually just not happy noone commented, now you have, so I'm happy. All is well again. |
| 10:18 | <annevk> | odinho: no it's not, the curious have no answers! |
| 10:18 | <Stevef> | annevk: I have had a glimpse of late into a world of backchannels I naively did not know existed |
| 10:18 | <odinho> | annevk: Or SimonSapin actually did, but I had forgot when I woke up this morning. |
| 10:19 | <odinho> | annevk: I'm scared of being flamed for obviously not knowing that "noone else had implemented that". :P |
| 10:19 | <odinho> | annevk: Or for "yeah, it's in the spec but you shouldn't use that you stupid!!!11" |
| 10:19 | <SimonSapin> | odinho: sorry I lost context |
| 10:19 | <annevk> | odinho: instead you'll be herrassed for not telling! |
| 10:19 | <odinho> | annevk: It's a tradeoff... ;-) |
| 10:20 | <SimonSapin> | odinho: what is this about? |
| 10:21 | <annevk> | Stevef: I'm guessing you're talking about <main>, since there's been a lot of that lately, but it would help my understanding if you were more concrete |
| 10:21 | <odinho> | annevk: Ohwell, it's only this small keyboardEvent.key. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-key |
| 10:22 | <annevk> | odinho: ah, yeah, that's not implemented :) |
| 10:22 | <annevk> | odinho: also, keyboard events are a mess |
| 10:22 | <odinho> | But I liked it. e.key == "Enter", e.key == "Down" |
| 10:22 | <odinho> | I was happy. |
| 10:23 | <odinho> | But then, TADA- does not work when my friend at my hackspace tried it. And imma like, I haven't yet tested other places than Opera *embarrasedface* :P |
| 10:24 | <Stevef> | annevk: yeah 'remember the <main>' |
| 10:24 | <annevk> | Stevef: so what backchannel was used there? |
| 10:25 | annevk | thought Hixie rejected it on whatwg⊙wo |
| 10:25 | <Stevef> | annevk: I wasn't saying that was a backchannel, just responding to you saying guessist about <main> |
| 10:26 | <Stevef> | found it amusing |
| 10:26 | <odinho> | SimonSapin: Oh, I'm Velmont at home... :P That's why you are loosing context. |
| 10:27 | Ms2ger | is getting more confused |
| 10:27 | <SimonSapin> | odinho: if you’re talking about DOM3 events, I’m not the one who commented on it |
| 10:27 | <Stevef> | annevk: will write a post about my experiences of late once the dust settles |
| 10:28 | <odinho> | SimonSapin: You did. I have logs, y'know ;-) |
| 10:28 | <annevk> | Stevef: Maybe you were talking about WAI then? They do indeed a lot of stuff in private... |
| 10:28 | <SimonSapin> | odinho: prove it :p |
| 10:28 | <odinho> | SimonSapin: http://krijnhoetmer.nl/irc-logs/whatwg/20121202#l-355 |
| 10:28 | <Stevef> | annevk: has nothing to do with WAI, they have not been involved |
| 10:29 | <annevk> | Stevef: The alluding that there's a problem somewhere, but not telling what it is, is kind of annoying. I wish you had written that post first. |
| 10:30 | <SimonSapin> | odinho: oh, that. I had no idea what the actual issues was about, just joking about standards guaranteeing interop |
| 10:31 | <Stevef> | annevk: well I am sorry for that, but was just riffing on the discussion |
| 10:32 | <odinho> | SimonSapin: That's commenting enough for me ;] |
| 10:37 | <zcorpan> | Hixie: maybe add a check for "<!DOCTYPE html> ..." in live dom viewer's filetestbug()? |
| 10:43 | <darobin> | haha, just got a bug report on ReSpec for a spec produced using Anolis :) |
| 10:43 | <zcorpan> | does anyone have a list at the top of their heads about what https://www.w3.org/Bugs/Public/show_bug.cgi?id=18460 needs to handle? |
| 10:44 | <annevk> | darobin: pointer? |
| 10:44 | <darobin> | annevk: you don't want to know, it's the XHR spec |
| 10:44 | <darobin> | the problem is that when served from https it's linking to a style sheet in http |
| 10:45 | <darobin> | which is blocked by a bunch of browsers, naturally |
| 10:45 | <annevk> | not sure that's natural actually |
| 10:45 | <darobin> | I guess Anolis could dynamically select the matching scheme when that happen |
| 10:45 | <darobin> | oh, wait, no it can't! |
| 10:46 | <annevk> | and you could just use a scheme-relative URL |
| 10:46 | <darobin> | yeah, but except that doesn't work great with file: |
| 10:47 | <annevk> | I'd still like to see this though, browsers block cross-scheme style sheet loads? |
| 10:47 | <annevk> | that's not defined anywhere I think |
| 10:49 | <annevk> | zcorpan: void elements; namespaced elements; elements without namespace; CDATA conversion (unless we get rid of that); <pre>\n and such |
| 10:50 | <annevk> | zcorpan: same stuff as innerHTML basically? |
| 10:51 | <zcorpan> | what do you mean with CDATA conversion? |
| 10:54 | <annevk> | turn it into text? |
| 10:55 | <zcorpan> | CDATA sections? |
| 10:56 | <annevk> | yeah, what else is there? |
| 10:59 | <zcorpan> | CDATA elements, though i guess they're called RAWDATA now |
| 10:59 | <SimonSapin> | annevk: I’ve seen browsers not blocking loading of cross-scheme stuff, but showing the page as "insecure" |
| 11:00 | <annevk> | SimonSapin: right |
| 11:00 | <darobin> | annevk: yes, look at https://dvcs.w3.org/hg/xhr/raw-file/988b577dec23/Overview.html in Chrome |
| 11:00 | <darobin> | I believe IE blocks that too |
| 11:00 | <darobin> | indeed I'm not aware of it being defined |
| 11:01 | <darobin> | maybe IE gives some form of insecure prompt, not sure |
| 11:01 | <darobin> | prompting has got to be the worst decision you can make there though |
| 11:01 | <darobin> | either allow it or don't, but don't ask the user |
| 11:02 | <annevk> | haha |
| 11:02 | <annevk> | Chrome blocks cross-scheme style sheets but allows cross-scheme XMLHttpRequest fetching? |
| 11:03 | <annevk> | I wonder what the rationale for that is |
| 11:04 | <darobin> | rationale? in a browser? |
| 11:06 | <annevk> | fair enough |
| 11:06 | <annevk> | they use jQuery in the XHR spec now? that's so funny |
| 11:07 | <annevk> | XHR is too hard for the editors of XHR, better use $.ajax |
| 11:16 | <darobin> | well, Julian actually wrote $.ajax so I don't think he finds XHR too hard |
| 11:21 | <annevk> | are the W3C lists slower these days? |
| 11:37 | <annevk> | what the fuck |
| 11:38 | <annevk> | gmail complaints my login period expires in the middle of me writing a long email |
| 11:38 | <annevk> | I login in a separate window |
| 11:38 | <annevk> | then my email gets trashed |
| 11:38 | <annevk> | oh, it's in drafts |
| 11:38 | <annevk> | close call |
| 14:01 | <annevk> | the fact that https://lists.w3.org/Archives/Team/team-html-chairs/ returns a 403 and https://lists.w3.org/Archives/Team/team-html-chairs2/ returns a 404 should tell people enough |
| 14:02 | <annevk> | it seems whoever created the meme made a typo in the other list |
| 14:02 | <annevk> | it's actually https://lists.w3.org/Archives/Team/team-html-editors/ |
| 14:04 | <Stevef> | annevk: i don't have permissions to view https://lists.w3.org/Archives/Team/team-html-editors/ archive... |
| 14:04 | <annevk> | Stevef: only the W3C Team does |
| 14:04 | <darobin> | can someone enlighten me on the sudden surge of interest in these two lists? |
| 14:04 | <Stevef> | even though I am subscribed |
| 14:05 | <Stevef> | darobin: its where the decisions are made |
| 14:05 | <darobin> | yes, by the brain slugs |
| 14:06 | <darobin> | bastard brain slugs! |
| 14:06 | <annevk> | I thought WHATWG made the decisions? |
| 14:06 | <darobin> | where are your brain slugs? |
| 14:06 | <annevk> | Anyway, I was just trying to point out how you could easily figure out if a list existed or not |
| 14:06 | <Stevef> | luckily I have all the decsions from https://lists.w3.org/Archives/Team/team-html-editors/ archived in gmail |
| 14:07 | <annevk> | I don't really have a stake in this game, other than enjoying the delicious memes |
| 14:07 | <annevk> | Stevef: better register w3cleaks.org |
| 14:08 | <Stevef> | annevk: and unleash a whole lot of broing on the world, why waste anymore of peoples time |
| 14:08 | <Stevef> | boring |
| 14:09 | <Stevef> | but maybe 'broing' too |
| 14:09 | <Stevef> | I have seen a bit of broing from darobin on the editors list for sure |
| 14:09 | <gsnedders> | OH GOD WHEN YOU HAVE MULTIPLE EDITORS AND CHAIRS THEY MIGHT COMMUNICATE AMONG THEMSELVES INSTEAD OF IN THEIR HEAD. |
| 14:10 | <gsnedders> | </sarcasm> |
| 14:10 | <gsnedders> | Basically, it seems inevitable that they'll have some means to communicate among themselves. |
| 14:10 | <Ms2ger> | gsnedders, sure, but do we get to read along? :) |
| 14:11 | <gsnedders> | Ms2ger: As much as we do read along inside Hixie's head, seemingly. |
| 14:12 | <Stevef> | i ahven't seen anything vaguely resembling a 'decision' made on the editors list, but was sorry to hear about darobins rash |
| 14:12 | <annevk> | gsnedders: Hixie's changes to the spec can almost always be derived from a public email and or bug report |
| 14:13 | <Stevef> | annevk: aren't a;;chnages to the html5 specs now available in git commits? |
| 14:13 | <Stevef> | or am i missing somehting? |
| 14:13 | <annevk> | Stevef: public commits != rationale |
| 14:14 | <annevk> | You want to be able to figure out why changes are made (and others not) in order to properly review them |
| 14:15 | <Stevef> | well silvia emails the html wg list regularly on chnanges made or not made |
| 14:16 | <gsnedders> | Right, lists of changes made. Not rationale. |
| 14:17 | <annevk> | The whole thing that led to this was Hixie not being able to figure out if the HTML editors made a mistake in not merging a WHATWG edit or if they had a reason for doing so |
| 14:19 | <Stevef> | annevk: if it was due to anything other than a mistake it will be documented publicly, editorial changes and interop chnages are added pretty much without question i.e. hixies rationale is the reason |
| 14:20 | <annevk> | Stevef: is there a public list of rejected changes then? |
| 14:21 | <Stevef> | silvia details what has not been merged in her emails for example http://lists.w3.org/Archives/Public/public-html/2012Nov/0154.html |
| 14:22 | <darobin> | gsnedders++ # funny |
| 14:22 | <annevk> | I don't really have any clue what the XHR editors are doing either, other than "pursuing convergence". A lot of the copy & pasting that is occurring these days strikes me as amateur hour and not really a viable strategy. |
| 14:22 | <darobin> | and yes, I do do a lot of broing there |
| 14:23 | <darobin> | annevk: put very simply, there is no decision about what commits go in that's made on the editors' list |
| 14:23 | <Stevef> | I am sure if things are clear enough for anybody that needs to know, that the editors will seek to provide all info in amanner that is public and understandable, no conspiracy needed |
| 14:23 | <darobin> | in fact, not much in the way of decisions apart from stuff like "hey, you folks okay if I move that spec-generating file over there?" |
| 14:24 | <Stevef> | I read each of silvias commit emails and respond to them (usually), I appear to be the only one that shows any interest... |
| 14:24 | <darobin> | I read silvia's emails but it's not impossible that I could miss stuff here and there |
| 14:25 | <darobin> | the point is: the commits that are merged are merged at the decision of whoever merges them |
| 14:25 | <gsnedders> | darobin: I is so wit. |
| 14:25 | <annevk> | I don't think there's much conspiracy, just a lack of insight into what is going on. Whether those lists are Team-only or world readable probably would not change much either way. |
| 14:25 | <darobin> | gsnedders: mucho wit! |
| 14:25 | <annevk> | Although for the Chairs list that might be different. |
| 14:25 | <darobin> | annevk: no matter what the access control you still can't read what's in people's brains (I think) |
| 14:26 | <darobin> | unless you're a brain slug |
| 14:26 | <Stevef> | annevk: only the chairs and illuminati know |
| 14:26 | <darobin> | the chairs' list is much the same... |
| 14:26 | <annevk> | darobin: but it's not about that... |
| 14:27 | <darobin> | annevk: there are two other things that it can be about: a better paper trail, or transparency everywhere |
| 14:27 | <darobin> | which? |
| 14:27 | <annevk> | I like both of those? :-) |
| 14:29 | <darobin> | hehe |
| 14:30 | <darobin> | things can probably be improved, but here's the breakdown for each |
| 14:30 | <darobin> | re the paper trail, everything that gets merged is listed as such |
| 14:30 | <darobin> | if there is no rationale, the rationale by default is that it's editorial or assumed consensual |
| 14:30 | <darobin> | if it wasn't, then there was a discussion on public-html |
| 14:31 | <darobin> | I guess those things could possibly be explained better, but that's the gist of it |
| 14:31 | <darobin> | re transparency, those lists are basically replacements for cc lists |
| 14:31 | <darobin> | they're not decision centres |
| 14:32 | <Stevef> | can we ask anyone inolved in the development of HTML to have all there standards work related email publicly archived, also their texts, conversations, gestures, and thoughts? |
| 14:32 | <Ms2ger> | Sure |
| 14:32 | <Ms2ger> | Everything except my identity |
| 14:32 | <darobin> | Stevef: sure we can, but as far as I know anything that matters is already public |
| 14:33 | <Stevef> | i know who you are you are Ms2ger |
| 14:33 | <darobin> | if you see a decision being made on team-* then that's a bug |
| 14:33 | <Ms2ger> | Oshi- |
| 14:33 | <darobin> | the only things that resemble decisions are about bikeshedding stuff |
| 14:33 | <Ms2ger> | darobin, so I wonder, why does it need to be team-*? |
| 14:33 | <annevk> | darobin: and the chair decisions? |
| 14:33 | <darobin> | and frankly, I would think it wonderful if all mailing lists had a separate hidden place for bikeshedding |
| 14:33 | <annevk> | darobin: before they become public |
| 14:34 | <Stevef> | darobin: "if you see a decision being made on team-* then that's a bug" I have not, but others claim they are |
| 14:34 | <darobin> | Stevef: "others"? |
| 14:34 | <Stevef> | well hixie and tab for example |
| 14:35 | <darobin> | Ms2ger: it makes it possible for us to discuss things like your identity without revealing it publicly |
| 14:35 | <Stevef> | which started this conversation |
| 14:35 | <darobin> | Stevef: so you're saying that people with no access to that list are stating that there's shady stuff going on there? |
| 14:35 | <Stevef> | yes |
| 14:35 | <darobin> | that's a lot of hooplah over a rumour.... |
| 14:36 | <Ms2ger> | I guess you don't see the issue |
| 14:36 | <darobin> | I mean, I could equally talk about the decisions made on private-whatwg⊙wo — those are really evil! |
| 14:37 | <hsivonen> | experience suggests “pursuing convergence” is not good |
| 14:38 | <Stevef> | darobin: hence my enquiry to the chairs http://lists.w3.org/Archives/Public/www-archive/2012Dec/0002.html |
| 14:39 | <darobin> | Stevef: you're on that list, I think you have a decent idea of the vital importance of the decisions we make their thanks to the brain slugs |
| 14:39 | darobin | initially wrote "brain sluts" there — not sure what to make of it |
| 14:39 | <darobin> | guess I'm a bit of a brain slut myself |
| 14:40 | <Stevef> | darobin: thats why I am trying to throw up a smoke screen of boring truth |
| 14:41 | <darobin> | yes, good — that way we can also keep the chupacabras hidden until they're done hatching |
| 14:42 | <Stevef> | darobin: when i amone of the chosen who gest to see the decisions behind the decisions and who really controls the whatwg's mutant child that is HTML5 |
| 14:46 | <Stevef> | it all hinges on the identity of 'the director' and I can assure you its not who you may think |
| 14:47 | <darobin> | the Director Brain Slug! |
| 14:50 | <hsivonen> | time to subscribe to yet another W3C mailing list. public-css-testsuite ahead. |
| 14:51 | <annevk> | hsivonen: why? |
| 14:52 | <hsivonen> | annevk: UTF-16 |
| 14:52 | gsnedders | still wonders why |
| 14:53 | <hsivonen> | gsnedders: http://w3cmemes.tumblr.com/post/35332222321/css-2-1-syndata-is-awesome |
| 14:53 | <gsnedders> | That's not a testsuite problem though? |
| 14:53 | <annevk> | hsivonen: ouch |
| 14:54 | <hsivonen> | it is when implementing Level 3 makes Level 2.1 tests fail and people notice |
| 14:54 | <annevk> | hsivonen: just read that Polyglot post and comments from Sam o_O |
| 14:57 | <gsnedders> | hsivonen: Ah, there's a process for dealing with that at least. |
| 15:28 | <zcorpan> | who created the lists? |
| 15:38 | <SimonSapin> | Re mailing lists: if you have a WC3 Member account, there is a tool for viewing who is subscribed to a list. Even if you’re not in that list, and even if the list is Team-only. |
| 15:40 | <gsnedders> | o_O |
| 15:41 | <SimonSapin> | don’t know if that’s a bug, but the tool is linked from the "Membership Administrivia" page |
| 15:42 | <annevk> | https://cgi.w3.org/member-bin/MailingListQuery.pl?queryList=team-html-editors |
| 15:42 | annevk | has no access anymore to verify |
| 15:42 | annevk | knows most of the links |
| 15:44 | <Ms2ger> | You're correct |
| 15:46 | <Ms2ger> | Interesting, it even has a "Last mail arrived" line |
| 15:46 | <darobin> | it's not a bug, it's just a mailing list audit tool |
| 15:46 | <SimonSapin> | darobin: is it a bug that I can query Team-only lists? |
| 15:46 | <Ms2ger> | "Interesting" != "bug" |
| 15:47 | <darobin> | SimonSapin: no |
| 15:47 | <darobin> | that ways you can always check your cc list to know whether someone really needs to be copied or not |
| 15:47 | <darobin> | of course, everyone does that! |
| 16:24 | <gsnedders> | http://www.w3.org/mid/1354040792.4860.822.camel⊙ll — final paragraph is beautiful (MO, sadly) |
| 16:28 | <Workshiva> | Secretsssss |
| 16:30 | <darobin> | hahaha, Liam's funny :) |
| 16:32 | <hsivonen> | gsnedders: I’m surprised by who takes what position in that thread |
| 16:41 | <annevk> | CSS WG violating its charter again? |
| 16:42 | <gsnedders> | annevk: No. |
| 16:56 | <darobin> | mmmm, does anyone know where it's defined what actually triggers resize events? |
| 16:56 | <darobin> | (if anywhere) |
| 16:58 | <Stevef> | hsivonen: is there a reason you talk about class names instead of id values in your mail about <main>? One of the confusions in the argument appears to be referring to class instead of id |
| 16:59 | <Stevef> | hsivonen: don't know if you saw this analysis i started working on last night: https://docs.google.com/spreadsheet/ccc?key=0AlVP5_A996c5dHozOW14RkF4NEdEUFRvemxCZ2I4Z3c |
| 17:03 | <TabAtkins> | SimonSapin: Argh, of course. I'll fix that. ^_^ |
| 17:07 | <dglazkov> | good morning, Whatwg! |
| 17:07 | <TabAtkins> | annevk: Do you expect to extend FormData into being a MultiMap as well? |
| 17:08 | <TabAtkins> | annevk: Even if not, the naming of the method isn't that important. Set uses Set#add for similar functionality, after all. |
| 17:08 | <TabAtkins> | MikeSmith: Thanks for the component! The delay wasn't important. |
| 17:11 | <TabAtkins> | zewt: I want to add numeric attribute comparisons in Selectors5. It's no problem grammatically. |
| 17:13 | <TabAtkins> | Stevef: I was just relaying the intended meaning of the meme. I dunno who actually authored it. |
| 17:16 | <hsivonen> | Stevef: Hixie’s chart claimed to be about classes, right? |
| 17:19 | <Stevef> | hsivonen: yes , one of issues with that data set is that no data on id values was published |
| 17:20 | <Stevef> | hsivonen: but use of main, content as class names has been used as argument why the values are not semantically menaingful and do not represent a main content area |
| 17:38 | <Stevef> | hsivonen: but I think that can be easily countered with reference to data like I pointed to above |
| 17:57 | <GPHemsley> | annevk: Do you suppose it would make sense to separate out all non-sniffing MIME stuff into a separate spec? |
| 17:57 | <GPHemsley> | annevk: I think this would help with, e.g., SimonSapin's data: spec, with regard to MIME type parsing. |
| 18:02 | <GPHemsley> | since a data: URL is basically "data:" <MIME type> "," <percent-encoded contents> |
| 18:06 | <GPHemsley> | well, <percent-encoded MIME type>, I guess |
| 18:11 | <SimonSapin> | GPHemsley: almost. You can also omit text/plain and just have parameters like data:;charset=foo,data |
| 18:11 | <SimonSapin> | but yeah, anything to help define parsing this would be great |
| 18:42 | <Hixie> | nessy: yt? |
| 18:43 | <GPHemsley> | SimonSapin: Yikes! Whose idea was that? |
| 18:45 | <SimonSapin> | don’t know, but it’s in the RFC |
| 18:45 | <GPHemsley> | eek |
| 18:47 | <SimonSapin> | http://tools.ietf.org/html/rfc2397#section-3 |
| 18:54 | GPHemsley | wonders if that was intended. |
| 18:54 | <GPHemsley> | SimonSapin: They don't show any examples using that, do they? Are there any in the wild? |
| 18:55 | <GPHemsley> | Although, I suppose if they didn't want that, they wouldn't have used square brackets at all... |
| 18:55 | <Hixie> | any people with IE around? |
| 18:55 | <SimonSapin> | GPHemsley: square brackets in the grammar, and prose in the section before |
| 18:56 | <Hixie> | looking for a description of what happens when you hit the buttons in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1974 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1979 |
| 18:58 | <GPHemsley> | SimonSapin: Just a PSA: Don't forget to read the errata. |
| 18:58 | GPHemsley | glances at the author of the document. |
| 19:03 | <GPHemsley> | SimonSapin: So, IIUC, you actually have two defaults if omitted: the MIME type (text/plain) and the charset (US-ASCII)? |
| 19:03 | <Hixie> | heycam: yt? |
| 19:05 | <Hixie> | GPHemsley: our shared list for getting accounts on the wiki isn't working, we're all hoping the other people will do it :-) |
| 19:06 | <GPHemsley> | Hixie: Oh, I usually do it. But it's hard to distinguish real requests from spam/misunderstandings. |
| 19:06 | <GPHemsley> | I'll check the archives and get to it. |
| 19:06 | <Hixie> | oh ok :-) |
| 19:07 | <Hixie> | i tend to leave them in my inbox until i see a reply or until i do it myself |
| 19:07 | <Hixie> | but i noticed recently there's three of them i haven't done that nobody else has done either :-) |
| 19:07 | <Yuhong> | <tantek> feel free to childrens-bookize this blog post: http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5 |
| 19:08 | <Yuhong> | Personally, I don't like this. It is basically suggest people write XML-valid markup, but omitting the xmlns because of a hate for namespaces which is silly. |
| 19:08 | <Hixie> | abarth: as far as i can tell, http headers are basically free |
| 19:09 | <Hixie> | abarth: possibly cheaper than harder working existing headers, at least :-) |
| 19:09 | <TabAtkins> | Yuhong: You're missing the very first subheading in the post, "Draconian = FAIL", which is a pretty huge benefit to not write XML. |
| 19:10 | <Yuhong> | Of course, but that blog article is suggesting making your markup XML-valid. |
| 19:10 | <Yuhong> | It can be a problem too (XSS), BTW. |
| 19:10 | <TabAtkins> | Yes? There's nothing wrong with trying your best to make your markup valid, while simultaneously valuing the fact that if you get it wrong (or down the line, some user-generated content mixed into your page gets it wrong), your page doesn't die. |
| 19:11 | <GPHemsley> | Hixie: OK, which is the third? |
| 19:11 | <TabAtkins> | XML doesn't stop XSS, either. At best, it turns some XSS attempts into DOSes. |
| 19:11 | <Yuhong> | Which is still better than nothing. |
| 19:12 | <Hixie> | GPHemsley: gotta go. i'll do the third if you replied to the others. |
| 19:12 | <Hixie> | bbiab |
| 19:12 | <Yuhong> | http://lcamtuf.blogspot.ca/2011/10/origin-is-forever.html |
| 19:12 | <GPHemsley> | k |
| 19:12 | <Yuhong> | But that is a different topic. |
| 19:12 | <TabAtkins> | I don't agree that a DOS is substantially better than an XSS. They're all bad, and all mean your page is broken. |
| 19:12 | <Yuhong> | Yes, but one is still better than the other in terms of security, see the link above. |
| 19:14 | <TabAtkins> | Again, though, the DOS only happens if you're incompetent with your XSS. If you know how your code is being inserted, you can always (maybe there's some times you can't?) craft it to remain well-formed and still XSS. |
| 19:15 | <TabAtkins> | In other words, it's not real security. And then you layer on the fact that lots of *non*-attack errors also cause a DOS, and you see there's no benefit. |
| 19:15 | <Yuhong> | I agree it is not a substitute for an XSS filter. |
| 19:16 | <Yuhong> | I'd suggest it as a defense-in-depth in case of bypass. |
| 19:16 | <Yuhong> | In fact, I said that before, I think. |
| 19:17 | <TabAtkins> | It's a defense-in-depth that triggers much more often on innocent things. In biology we call that an auto-immune disorder. |
| 19:18 | <Yuhong> | In any case, it is not what the blog article is advocating anyway. |
| 19:18 | <Yuhong> | They are advocating "XML-valid" HTML5. |
| 19:18 | <Yuhong> | Which does not make sense. |
| 19:19 | <Yuhong> | And does not provide much benefit over just putting the xmlns. |
| 19:33 | <TabAtkins> | The benefit over not putting in the xmlns is what I've already said - your page doesnt' break when you get your validity wrong. |
| 19:41 | <abarth> | Hixie: :) |
| 19:56 | <annevk> | TabAtkins: I've had requests to make FormData editable like a map |
| 19:56 | <annevk> | TabAtkins: and to seed a <form> with FormData, etc. |
| 19:57 | <annevk> | TabAtkins: so yes, it would be a MultiMap like URLQuery except that it's backend is multipart/form-data rather than application/x-www-form-urlencoded |
| 19:57 | <annevk> | (both are really quite terrible formats, I wish they had done a better job back in the day) |
| 19:58 | <annevk> | GPHemsley: I prefer not to have too many specifications |
| 19:59 | <GPHemsley> | annevk: Well, I think sniffing is a bit more niche of an issue than e.g. MIME type parsing. |
| 20:00 | <SimonSapin> | GPHemsley: if the whole <mediatype> is omitted, it defaults to text/plain;charset=US-ASCII |
| 20:00 | <annevk> | GPHemsley: I suppose, but that's not directly a reason to create a new specification |
| 20:00 | <SimonSapin> | I don’t know if only whitespace or percent-escaped whitespace counts as omitted |
| 20:01 | <annevk> | GPHemsley: We might move concepts around over time, as we figure out their appropriate place, but if we don't know the place yet, it might as well be close to the other MIME stuff |
| 20:01 | <SimonSapin> | If <type> "/" <subtype> is omitted, it defaults to text/plain |
| 20:01 | <annevk> | SimonSapin: note that US-ASCII means windows-1252 |
| 20:01 | <GPHemsley> | annevk: Because it really has nothing to do with MIME types, really. It's just about identifying what format a resource uses. The MIME type concept is merely one way to formalize it. |
| 20:01 | <SimonSapin> | annevk: yes |
| 20:01 | <GPHemsley> | annevk: Which is basically what you were arguing for fonts. |
| 20:02 | <GPHemsley> | SimonSapin: text/plain in what charset? |
| 20:02 | <GPHemsley> | err |
| 20:02 | <annevk> | GPHemsley: again, we don't know the appropriate place yet :) |
| 20:02 | <annevk> | It might be that most of this needs to come together in Fetch somehow |
| 20:03 | <SimonSapin> | GPHemsley: no default charset in the later case. The point is to only specify the charset, as in data:;charset=foo,data |
| 20:03 | <GPHemsley> | SimonSapin: Yeah, I'm trying to figure out what question I actually want to ask you... |
| 20:04 | <GPHemsley> | annevk: FYI, this MIME type parsing algorithm is turning out to be a lot longer than I expected. |
| 20:04 | <annevk> | GPHemsley: I think you argue that we should find the place and that if we cannot find it let it be a separate document. And I argue that lets just define it and move it once we figure out the appropriate architecture. |
| 20:04 | <GPHemsley> | SimonSapin: Oh, I mean, what if the type is specified without a charset parameter? |
| 20:05 | <GPHemsley> | annevk: What I'm really arguing is that I don't want to overload mimesniff with all this stuff that has nothing to do with it. Whether it's in Fetch or a brand new document doesn't matter much to me. |
| 20:05 | <annevk> | (My point about Fetch was that MIME sniffing might need to be in Fetch.) |
| 20:06 | <GPHemsley> | oh |
| 20:06 | GPHemsley | doesn't know much about what Fetch is for. |
| 20:06 | <SimonSapin> | not about fetching :p |
| 20:06 | <annevk> | Fetch takes a URL and returns a resource. |
| 20:07 | <GPHemsley> | So... URL -> Fetch -> MIME Sniffing? |
| 20:07 | <annevk> | But it does a whole lot more too, such as giving feedback as to when to dispatch progress events, whether or not to follow redirects for HTTP requests, how to apply CORS headers, how to set Referer, etc. |
| 20:08 | <GPHemsley> | So wait... is Fetch incoming or outgoing? |
| 20:08 | <annevk> | GPHemsley: Yeah, might be. And the reason it makes sense to have MIME type parsing defined in MIME sniffing is that MIME sniffing depends on how Content-Type is parsed sometimes... |
| 20:08 | <SimonSapin> | annevk: a quick glance at fetch.spec.whatwg.org makes it look like it’s about whether you’re allowed to fetch, not about the fetching itself. In my mind fetching would be an HTTP client, data: parser etc. |
| 20:08 | <annevk> | SimonSapin: your quick glance missed the red box at the top I think |
| 20:09 | <SimonSapin> | annevk: indeed |
| 20:09 | GPHemsley | wonders if we should sit down and determine some sort of relationship document about the various specs. |
| 20:09 | <annevk> | GPHemsley: Is that not what we do whenever it's design time in #whatwg? :-) |
| 20:10 | <GPHemsley> | Oh, I didn't get the memo. When's the next design time? :) |
| 20:10 | <GPHemsley> | I'm thinking something like this: |
| 20:11 | <GPHemsley> | URL -> Fetch -> MIME Sniffing -> MIME -> HTML |
| 20:11 | <GPHemsley> | (or perhaps MIME -> MIME Sniffing, depending on the scope of each) |
| 20:12 | <annevk> | or perhaps Fetch -> MIME -> HTML trololo |
| 20:12 | <annevk> | e.g. http://mimesniff.spec.whatwg.org/#determining-the-sniffed-media-type-of-a-resource does some MIME type parsing |
| 20:13 | <annevk> | it does byte comparisons on the value of Content-Type |
| 20:13 | <SimonSapin> | would data: be part of Fetch? (And would it be cross-origin?) |
| 20:13 | <annevk> | SimonSapin: yes and ideally it's treated as same-origin unless there was a redirect |
| 20:14 | <annevk> | SimonSapin: at least that's the model I've been thinking of which would work for XHR/Workers/<canvas>/etc. that want data: URLs to work |
| 20:14 | <GPHemsley> | annevk: And perhaps that could be abstracted out to MIME or Fetch, since there are multiple ways to trigger the no-sniff flag. |
| 20:15 | <SimonSapin> | WebKit refuses to let me test data: in anyway because it is supposedly cross-origin :( |
| 20:15 | <GPHemsley> | Leaving MIME Sniffing to only be the matching resource byte patterns part |
| 20:15 | <annevk> | GPHemsley: so my idea is that Fetch gets the bits; MIME determines who gets to handle the bits; HTML/SVG/CSS/JavaScript handle the bits |
| 20:16 | <annevk> | with "who" being the format specs |
| 20:16 | <SimonSapin> | the only sign of life I can get is with data:text/html,<script>window.parent.postMessage('something', '*')</script> |
| 20:16 | <SimonSapin> | but that’s not exactly simple |
| 20:16 | <GPHemsley> | right, hmm |
| 20:17 | <SimonSapin> | (in an iframe) |
| 20:17 | <annevk> | SimonSapin: yeah, that's a bug in WebKit but they're not compelled to fix it at this stage I think |
| 20:17 | <annevk> | SimonSapin: hopefully once we have clearer specs... |
| 20:17 | <GPHemsley> | annevk: In that case, the sniffing wouldn't return a MIME type so much as a format to parse...? |
| 20:17 | <SimonSapin> | compelled? |
| 20:17 | <GPHemsley> | annevk: Or is it merely transforming a HTTP MIME type to a handler MIME type? |
| 20:18 | <GPHemsley> | annevk: Or, put another way, transforming an untrusted MIME type into a trusted MIME type. |
| 20:18 | <SimonSapin> | annevk: I think that some things like @import bypass MIME completely |
| 20:18 | <annevk> | GPHemsley: or finding a MIME type (if there was none) |
| 20:19 | <GPHemsley> | annevk: "" is an untrusted MIME type ;) |
| 20:19 | <annevk> | GPHemsley: and no Content-Type header is too I guess? sure |
| 20:19 | <GPHemsley> | "You silly server. All resources have types!" |
| 20:20 | <aklein> | annevk: hi there. I take it from your resolution of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20131 that you were swayed by the consistency argument re: mutation record identity? |
| 20:21 | <annevk> | aklein: I was also swayed by the lack of further resistance, the simplicity of doing what smaug asked for (and Microsoft seemed to ask for), and the lack of clarity in what exactly the WebKit model would be and whether that would be error proof (smaug seemed to demonstrate a few unexpected cases) |
| 20:22 | <aklein> | annevk: k. I'm still a bit concerned about the memory impact, but I don't have data to show, and if it is really bad smaug is right that we could go to extra effort to optimize it (e.g., share the impl and hand out unique wrappers) |
| 20:23 | <annevk> | SimonSapin: yes so an API (say @import) does Fetch + MIME and then decides whether what to do is probably closer to the model |
| 20:28 | <annevk> | aklein: I was not really swayed by the expandos argument fwiw. Just that what WebKit did was not consistent and what smaug proposed was simple and straightforward. |
| 20:30 | <aklein> | annevk: good to know. I knew that oldValue design would bite us! :) |
| 20:41 | <GPHemsley> | annevk: Oh, another thing I was going to add was aliases (like Encoding) that are interpreted as the canonical MIME type... but now I'm thinking the resource handlers should be the "canonical" output. ...? |
| 20:42 | <GPHemsley> | since a lot of the Web types have multiple MIME types associated with them |
| 20:42 | <annevk> | GPHemsley: example? |
| 20:42 | <annevk> | GPHemsley: oh, like text/xml vs application/xml? |
| 20:42 | <GPHemsley> | sure |
| 20:42 | <GPHemsley> | or "The official IANA-registered MIME type for ICO files is image/vnd.microsoft.icon, registered in 2003. Erroneous labels "image/ico", "image/icon", "text/ico" and "application/ico", along with the unofficial name "image/x-icon" were in use at the time of official registration and assignment of the MIME type.[8]" |
| 20:43 | <annevk> | I guess that one is always sniffed or do UAs actually recognise those MIME types? |
| 20:44 | <GPHemsley> | I don't know about this particular one, but I know there are formats that they accept multiple MIME types for. |
| 20:44 | <GPHemsley> | (Don't know off the top of my head which ones) |
| 20:44 | <GPHemsley> | WAVE is similar |
| 20:44 | <GPHemsley> | (Funnily enough, UAs don't accept the one WAVE type registered at IANA) |
| 20:45 | <annevk> | yeah, don't pay too much attention to IANA I guess |
| 20:45 | <annevk> | it's a mess for encodings too |
| 20:45 | <GPHemsley> | annevk: Well, my point is, the MIME type is treated as holy, when all that matters is what parser parsers the file (or handler handles, etc.) |
| 20:46 | <GPHemsley> | so MIME types and sniffing are just ways to funnel resources to the appropriate handler |
| 20:46 | <annevk> | GPHemsley: yeah, but SimonSapin is right that MIME might not be the right place to make the call about the handler |
| 20:46 | <GPHemsley> | annevk: Oh, did he say that? |
| 20:46 | <annevk> | GPHemsley: e.g. XMLHttpRequest sometimes pays attention, but often ignores MIME |
| 20:46 | <annevk> | GPHemsley: <script> always ignores MIME |
| 20:47 | <GPHemsley> | annevk: Not true if the no-sniff flag is set, at least in IE> |
| 20:47 | <SimonSapin> | I’m saying MIME is sometimes bypassed/ignored |
| 20:47 | <GPHemsley> | . |
| 20:48 | <GPHemsley> | So maybe we should be registering handlers instead of MIME types |
| 20:48 | <annevk> | GPHemsley: right, but I guess you see my point how it depends on the API? |
| 20:48 | <GPHemsley> | annevk: I actually think you're making an orthogonal point. |
| 20:48 | <GPHemsley> | Or missing mine |
| 20:49 | <annevk> | I'm saying that e.g. with XHR if I Fetch something labeled image/x-icon I don't want it to be handled by the image library |
| 20:49 | <GPHemsley> | annevk: What should it be handled by? |
| 20:50 | <annevk> | GPHemsley: by XHR |
| 20:50 | <GPHemsley> | annevk: So then XHR requests shouldn't pass through the MIME tunnel |
| 20:50 | <GPHemsley> | that's simple |
| 20:50 | <GPHemsley> | isn't it? |
| 20:50 | <annevk> | GPHemsley: they should, because XHR does care about the MIME type sometimes |
| 20:51 | <GPHemsley> | when? |
| 20:51 | <annevk> | GPHemsley: so I want a resource with a parsed MIME type (no MIME sniffing I suppose) |
| 20:51 | <annevk> | GPHemsley: http://xhr.spec.whatwg.org/#document-response-entity-body |
| 20:52 | <SimonSapin> | uhm, I might have imagined the bit about @import ignoring Content-Type. Can’t find it in any spec |
| 20:55 | <SimonSapin> | I think it’s actually undefined what happens when @import points to something that is not text/css |
| 20:55 | <SimonSapin> | TabAtkins: any opinion on that? |
| 20:58 | <annevk> | SimonSapin: I think for CSS it should be respected actually most of the time |
| 20:58 | <annevk> | SimonSapin: with some same-origin quirks mode exception perhaps |
| 20:59 | <SimonSapin> | so it would be an error? |
| 20:59 | <SimonSapin> | (which means maybe a log message in some console, and then ignored) |
| 21:01 | <annevk> | SimonSapin: yes |
| 21:11 | <TabAtkins> | SimonSapin: Nope, well defined. You just parse it as CSS. For most things that aren't CSS, that'll just result in a big pile of parse errors and no actual rules. |
| 21:11 | <TabAtkins> | The CSS parser is defined over all possible bitstreams. |
| 21:12 | <SimonSapin> | TabAtkins: so I remembered right, but I can’t find a reference for that |
| 21:13 | <TabAtkins> | If there's no text explicitly restricting @import based on Content-Type, then there's no restriction, and you just do what comes naturally. ^_^ |
| 21:16 | <SimonSapin> | I never know if something is obvious enough that it doesn’t need to be mentioned in the specs, or if it’s only obvious to us based on prior knowledge |
| 21:16 | <GPHemsley> | annevk: IIUC, needs to distinguish HTML and XML from everything else. Is that right? |
| 21:16 | <GPHemsley> | XHR needs |
| 21:16 | <TabAtkins> | I consider restrictions never obvious, and always needing explicit statement. |
| 21:17 | <SimonSapin> | what says that the thing pointed to by @import is CSS and not some other kind of stylesheet? |
| 21:17 | <GPHemsley> | TabAtkins: So, wait, do CSS files not need to be tagged? |
| 21:17 | <GPHemsley> | as text/css |
| 21:17 | <SimonSapin> | what if someone starts serving text/css+sass? |
| 21:17 | <annevk> | SimonSapin: I think TabAtkins is saying that CSS needs to be fixed at some point to define the processing model |
| 21:18 | <SimonSapin> | GPHemsley: @import could be different from <link rel=stylesheet> |
| 21:18 | <SimonSapin> | annevk: what’s a processing model? |
| 21:18 | <GPHemsley> | ah, so you can't CSS-@import XSL, for example |
| 21:19 | <GPHemsley> | once you're in CSS mode, you're assumed to always be in CSS mode? |
| 21:19 | <annevk> | SimonSapin: a set of steps that define what to do; e.g. fetch, check MIME type, throw away if not text/css otherwise apply |
| 21:19 | <annevk> | GPHemsley: XHR also cares about the charset parameter value |
| 21:20 | <TabAtkins> | SimonSapin, annevk: We can certainly clarify that @import is always interpreted as text/css. |
| 21:20 | <TabAtkins> | We assumed it was obvious. ^_^ |
| 21:20 | <annevk> | TabAtkins: that's not the processing model |
| 21:20 | <annevk> | TabAtkins: pretty sure @import rejects e.g. text/xml files |
| 21:20 | <TabAtkins> | annevk: I suspect this needs some testing. |
| 21:21 | <TabAtkins> | Like, what about text/plain? |
| 21:21 | <GPHemsley> | annevk: What has the power to initiate an XHR request? |
| 21:21 | <SimonSapin> | annevk: I think Tab meant that this stuff is obvious enough that it doesn’t even need to be written down |
| 21:21 | <annevk> | GPHemsley: the XHR API? |
| 21:21 | <TabAtkins> | I know that I can do "<link rel=stylesheet href=style.php>" and it just works. |
| 21:21 | <annevk> | TabAtkins: if you do header("content-type:text/css") |
| 21:21 | <TabAtkins> | SimonSapin: Though this conversation proves that I was wrong, and it's not obvious. ^_^ |
| 21:21 | <fantasai> | IIRC, we're pretty strict about whether CSS sheets have the right content type |
| 21:21 | <fantasai> | header |
| 21:21 | <GPHemsley> | annevk: And what has the power to use the XHR API? |
| 21:22 | fantasai | doesn't know if that's changed in recent years, but it used to be a problem for servers sending it over as text/plain |
| 21:22 | <TabAtkins> | annevk: I don't think I've done that before. I think I've just served naked PHP files without explicit declarations and they worked. |
| 21:22 | <annevk> | GPHemsley: web developers? |
| 21:22 | TabAtkins | goes to test. |
| 21:22 | <GPHemsley> | annevk: I'm talking about file types here, not people. |
| 21:22 | <SimonSapin> | GPHemsley: scripts? |
| 21:22 | <annevk> | TabAtkins: be sure to test standards/quirks and same-origin and cross-origin |
| 21:23 | <annevk> | GPHemsley: that's not relevant? |
| 21:23 | <GPHemsley> | annevk: What do you mean? |
| 21:24 | <annevk> | GPHemsley: that it's not relevant who or what initiates XHR |
| 21:24 | <GPHemsley> | annevk: Not relevant to what? |
| 21:24 | <annevk> | anything |
| 21:24 | <SimonSapin> | by the way, WeasyPrint does not know anything about cross-origin. HTTP documents are allowed to use images (including SVG) and stylesheets in file:// |
| 21:24 | <SimonSapin> | Not sure how much of an issue that is, given there is no JS at all |
| 21:24 | <GPHemsley> | annevk: I'm trying to understand what has the ability to perform an XHR request. |
| 21:25 | <annevk> | GPHemsley: it's not clear what you mean by "what" |
| 21:25 | <GPHemsley> | annevk: All values of "what" that are digital. |
| 21:25 | <annevk> | GPHemsley: you lost me |
| 21:26 | <GPHemsley> | annevk: I don't know how XHR works. I'm trying to understand what it is and who/what uses it. |
| 21:26 | <GPHemsley> | and "developers" does not help me |
| 21:26 | <TabAtkins> | annevk: Blast, you're right. Standards-mode fails without Content-Type, quirks mode don't care. |
| 21:27 | <SimonSapin> | TabAtkins: what about a content-type other than text/css? |
| 21:27 | <annevk> | TabAtkins: not surprised :-) |
| 21:27 | <TabAtkins> | SimonSapin: Let's see! |
| 21:27 | <annevk> | GPHemsley: does http://xhr.spec.whatwg.org/#introduction help? |
| 21:27 | <SimonSapin> | GPHemsley: JavaScript can use XHR. Is this the kind of answer you’re looking for? |
| 21:28 | <GPHemsley> | SimonSapin: Yes, thank you. Can anything besides JS use XHR? |
| 21:28 | <TabAtkins> | SimonSapin: text/html fails, while an explicit text/css works. |
| 21:28 | <TabAtkins> | GPHemsley: XHR is a JS API, so no. |
| 21:28 | <GPHemsley> | TabAtkins: OK, so that's what I was looking for. Thanks. |
| 21:28 | <TabAtkins> | Plenty of things can make requests, of which XHR is one. |
| 21:28 | <SimonSapin> | GPHemsley: if the web had other scripting languages, maybe |
| 21:29 | <annevk> | XHR is Fetch's API |
| 21:29 | <TabAtkins> | Okay, looks like I need to spec this in Cascade real quick. |
| 21:29 | <GPHemsley> | SimonSapin: But the bottom line is, you're already in the HTML/XML/JS handler if you're making an XHR request? |
| 21:29 | <annevk> | TabAtkins: fyi, Hixie has this covered in HTML for <link>, so you might want to use the same language |
| 21:29 | <TabAtkins> | annevk: What's the proper way to say "if the content-type header is text/css"? Anything I need to look out for? |
| 21:30 | <TabAtkins> | Okay, good, I'll check that out. |
| 21:31 | <GPHemsley> | TabAtkins: In MIME Sniffing I define "media type portion"; alternatively, you can say the type is "text" and the subtype is "css". |
| 21:31 | <SimonSapin> | TabAtkins: if you’re parsing the bytes in the header, things to look for are casing, whitespace, … But you might just refer to the result of that parsing with something like "if the response has a text/css MIME type" |
| 21:31 | <SimonSapin> | GPHemsley: "media type" means something else in CSS :/ (think media queries) |
| 21:32 | <GPHemsley> | Oh, right |
| 21:32 | <GPHemsley> | terminology is complicated here |
| 21:32 | <TabAtkins> | SimonSapin: I'm just going to do what HTML is doing. |
| 21:32 | <annevk> | well MIME should call it MIME type |
| 21:32 | <GPHemsley> | because I can't really say the "MIME type portion of the MIME type", either |
| 21:32 | <annevk> | it's not complicated |
| 21:32 | <TabAtkins> | It just refers to "Content-Type metadata" and defers to the MIMESNIFF spec. |
| 21:33 | <annevk> | GPHemsley: A *MIME type* consists of a *type* and *parameters* or some such? |
| 21:33 | <GPHemsley> | TabAtkins, SimonSapin: But these are things that I was hoping to tackle with the separate MIME spec (or wherever it would land), with MIME type parsing. |
| 21:33 | <GPHemsley> | annevk: "type" is overloaded too, as the part before the slash |
| 21:34 | <annevk> | I guess then type, subtype, and parameters |
| 21:35 | <SimonSapin> | In my mind, Content-Type is a MIME type + a map/dict of parameters. charset is a parameter. But maybe I get it wrong. |
| 21:35 | <annevk> | and just MIME type as the shorthand |
| 21:35 | <GPHemsley> | annevk: Yeah, that's how I'm doing it in the parsing algorithm I'm currently writing |
| 21:35 | <annevk> | SimonSapin: charset is tied to the MIME type, though in practice UAs sometimes support it for all MIME types, depending on what algorithm is running |
| 21:35 | <GPHemsley> | SimonSapin: That sounds about right. The complication is that a "MIME type" is made up of a "type" and a "subtype". |
| 21:36 | <annevk> | SimonSapin: e.g. XHR supports it for all MIME types, which is technically a bug |
| 21:36 | <GPHemsley> | annevk, SimonSapin: One of the questions here is whether "MIME type" includes the parameters or not. |
| 21:36 | <SimonSapin> | well, we need of term for something that does not |
| 21:37 | <SimonSapin> | in Python server side APIs, that term is often "MIME type" |
| 21:37 | <GPHemsley> | I'm OK with that |
| 21:37 | <SimonSapin> | but that could just be a confusion |
| 21:38 | <GPHemsley> | perhaps "MIME type" is type + subtype, and "content type" is type + subtype + parameters? |
| 21:38 | <SimonSapin> | works for me |
| 21:38 | <GPHemsley> | (and then we can leave "media type" for CSS media queries) |
| 21:39 | <SimonSapin> | though it can get confusing quickly |
| 21:39 | <GPHemsley> | well, it already is |
| 21:39 | <GPHemsley> | so the question is: does this make it better or worsE? |
| 21:39 | <SimonSapin> | but I never really though of type and subtype separately |
| 21:39 | <SimonSapin> | GPHemsley: compared to what? Do we have another proposal? |
| 21:39 | <GPHemsley> | SimonSapin: Compared to whatever the status quo is |
| 21:40 | <annevk> | GPHemsley: it does |
| 21:40 | <SimonSapin> | I don’t know what the status quo is :/ |
| 21:40 | <SimonSapin> | apart from confusion |
| 21:40 | <GPHemsley> | SimonSapin: So then this is better, no? :P |
| 21:40 | <SimonSapin> | I guess |
| 21:41 | <GPHemsley> | annevk: It does make it better? |
| 21:41 | <annevk> | GPHemsley: MIME type includes parameters |
| 21:41 | <SimonSapin> | well, this set of term *is* my opinion of the status quo, so it’s the same :p |
| 21:41 | <GPHemsley> | annevk: Oh. Argh. |
| 21:41 | <SimonSapin> | annevk: does it? :/ |
| 21:41 | <annevk> | I just explained that above |
| 21:42 | <GPHemsley> | Did you? |
| 21:44 | <GPHemsley> | Oh, HTTP (which defines the syntax) calls type + subtype + parameters "media-type" |
| 21:44 | <GPHemsley> | (or Internet Media Type, in plain English) |
| 21:44 | <GPHemsley> | http://tools.ietf.org/html/rfc2616#section-3.7 |
| 21:44 | <SimonSapin> | the data: RFC references MIME, not HTTP … |
| 21:45 | <TabAtkins> | annevk: Does this look okay? http://dev.w3.org/csswg/css3-cascade/#import-content-type |
| 21:45 | TabAtkins | isn't quite sure of how to do it correctly. |
| 21:45 | <GPHemsley> | SimonSapin: Which MIME RFC? |
| 21:46 | <annevk> | TabAtkins: "same-origin" |
| 21:46 | <TabAtkins> | The HTML source doesn't hyphenate. |
| 21:46 | <annevk> | TabAtkins: "Otherwise, if the resource's type denotes a type of stylesheet that the user agent understands, it must be interpreted as defined by that type." can probably be removed as this is CSS specific |
| 21:47 | <annevk> | TabAtkins: ah yeah, not needed here, but a space is |
| 21:47 | <TabAtkins> | annevk: Then I need to loosen the final "otherwise" to be "or else do whatever", right? |
| 21:47 | <TabAtkins> | Whoops, didn't intend them to be one word. |
| 21:47 | <SimonSapin> | RFC2397 (data:) references RFC2045 (MIME) to define "type", "subtype", "attribute" and "value" |
| 21:47 | <annevk> | TabAtkins: "If the linked resource's type is text/css, it must be interpreted as a CSS stylesheet, and as a network error otherwise." maybe? |
| 21:48 | <SimonSapin> | TabAtkins: so you would allow other stylesheet types in @import? |
| 21:48 | <TabAtkins> | annevk: And let other specs override the final clause? |
| 21:49 | <annevk> | TabAtkins: this is CSS cascade, @import is not ever going to import non-CSS without CSS itself changing |
| 21:49 | <GPHemsley> | SimonSapin: Ah, they're effectively the same. HTTP is newer, and doesn't embed the name of the header into the value. |
| 21:50 | <annevk> | TabAtkins: just issue a new cascade once that situation arrives rather than let people speculate over what it might mean and imply |
| 21:50 | <TabAtkins> | annevk: I'm not sure I see why that shoudl be true. If you recognize another stylesheet language that is nevertheless compatible with the cascade (text/css+sass), it would make sense to let that be @import-able. |
| 21:50 | <TabAtkins> | But I'm fine if that's done by just letting the extension spec override the restriction. |
| 21:51 | <SimonSapin> | TabAtkins: what about stylesheets that do not have cascading rules? |
| 21:51 | <SimonSapin> | XSL? |
| 21:52 | <annevk> | ^^ is what I mean |
| 21:52 | <annevk> | Is any browser planning on supporting text/css+sass? |
| 21:53 | <SimonSapin> | I pulled it out of thin air, don’t speculate (only) based on what I say |
| 21:53 | <GPHemsley> | SimonSapin: BTW, I meant to tell you that I added you as a permanent autoconfirmed user on the wiki, so the CAPTCHAs should have gone away (if they hadn't already) |
| 21:54 | <SimonSapin> | GPHemsley: Great! But I moved data: to github pages now :) |
| 21:54 | GPHemsley | shrugs. |
| 21:54 | <SimonSapin> | thanks anyway |
| 21:55 | <TabAtkins> | SimonSapin: Dunno! Presumably the extension spec defining how that stuff works would do it. |
| 21:55 | <TabAtkins> | annevk: I don't see the difference between @importing an XSL stylesheet and just linking both an XSL and CSS stylesheet. |
| 21:56 | <GPHemsley> | Hmm... two hours ago I came onto the computer to look at how quoted strings work, and I still haven't looked it up... |
| 21:56 | <SimonSapin> | @import is supposed to have a "source order" compared to other @imports |
| 21:56 | <annevk> | TabAtkins: @import is CSS-specific. <link> is not. Although I think the idea HTML might somehow work with another style sheet language is pretty far fetched and we should probably drop that notion in favor of just crossing that bridge when we get there. |
| 21:57 | fantasai | thought there were some implementations that supported XSLT through <link> ? |
| 21:57 | <TabAtkins> | SimonSapin: For the purpose of the CSS cascade, it is. If the other language doesn't use our cascade, then that effect is irrelevant. |
| 21:57 | <TabAtkins> | annevk: Anyway, I've adopted your language and made the otherwise clause just a network error. This discussion is academic and pending another stylesheet language actually wanting to interoperate with CSS and get adopted. ^_^ |
| 21:57 | <annevk> | fantasai: that would be news to me; although I think in the past I might have mistakenly pushed for it a bit... |
| 21:57 | <GPHemsley> | Oh, argh. Curse you, RFC 822 comments! |
| 21:58 | <SimonSapin> | TabAtkins: could work. I feel like annevk that @import in CSS-specific but not a strong opinion |
| 21:58 | <TabAtkins> | The current language supports it being CSS specific. Extension specs can always override the clause if we want to change it in the future. |
| 21:58 | <SimonSapin> | GPHemsley: data: indirectly references 822 too |
| 21:59 | <GPHemsley> | SimonSapin: Well, I would hope they were at least the same crazy allowances. :P |
| 21:59 | <SimonSapin> | through 2045 |
| 21:59 | <GPHemsley> | (Though I know that is often not the case) |
| 21:59 | <GPHemsley> | SimonSapin: Yeah, that's what I'm looking at. |
| 22:00 | <SimonSapin> | GPHemsley: another fuzzy point for me is when percent-decoding happens for the data: header, relative to other parsing steps |
| 22:00 | <GPHemsley> | SimonSapin: Well, presumably it doesn't matter, no? |
| 22:01 | GPHemsley | is not directly looking at your data: spec or the RFC |
| 22:01 | <GPHemsley> | SimonSapin: You've got two relatively independent chunks, with additional text that isn't percent-encoded |
| 22:01 | <annevk> | SimonSapin: it seems kinda logical to decode to bytes and then use a byte parser for MIME |
| 22:02 | <annevk> | SimonSapin: but, if that's not what implementations do... |
| 22:02 | <GPHemsley> | SimonSapin: I am defining this algorithm assuming I am getting a straight string of text (no percent-encoding, etc.) |
| 22:02 | <GPHemsley> | SimonSapin: It'll be up to you to manipulate what you have to be valid input to the algorithm :P |
| 22:03 | <SimonSapin> | GPHemsley: I don’t know … in text/plain%3Bcharset=utf8 is charset part of the subtype? is utf8? |
| 22:03 | <SimonSapin> | text/plain%3Bcharset%3Dutf8 |
| 22:03 | <GPHemsley> | SimonSapin: Oh dear. It seems Firefox says no. |
| 22:03 | <GPHemsley> | err, yes |
| 22:04 | <GPHemsley> | so... is the content type not supposed to be percent-encoded? |
| 22:04 | <GPHemsley> | what happens if it has spaces? |
| 22:04 | <SimonSapin> | GPHemsley: I read rfc2397 a few times, and I have no idea |
| 22:05 | <SimonSapin> | try percent-encoded whitespace |
| 22:05 | <GPHemsley> | SimonSapin: That seems to be decoded. |
| 22:05 | <GPHemsley> | %20, anyway |
| 22:06 | <SimonSapin> | is it interoperable? |
| 22:06 | <GPHemsley> | but it doesn't copy & paste as percent-encoded |
| 22:06 | <GPHemsley> | (which I think would be expected) |
| 22:07 | <GPHemsley> | Opera loads it, but doesn't decode it |
| 22:07 | <SimonSapin> | does it behave the same in an address bar or an attribute? |
| 22:07 | <SimonSapin> | (HTML attribute) |
| 22:07 | <GPHemsley> | same with Chrome |
| 22:08 | <GPHemsley> | and Safari |
| 22:08 | <GPHemsley> | so Opera, Chrome, and Safari allow %20 and do not decode it |
| 22:08 | <SimonSapin> | allow where? |
| 22:08 | <GPHemsley> | Firefox allows it, but decodes it to space |
| 22:08 | <GPHemsley> | in the location bar |
| 22:08 | <SimonSapin> | I mean where in the URL |
| 22:08 | <GPHemsley> | oh |
| 22:08 | <GPHemsley> | data:text/plain;%20charset=utf8,test |
| 22:09 | <GPHemsley> | but note that if you load that in Firefox and copy it back, you get: |
| 22:09 | <GPHemsley> | data:text/plain; charset=utf8,test |
| 22:09 | <SimonSapin> | hum, firefox gives the download dialog for data:text/plain%20;charset=utf8,tést |
| 22:10 | <SimonSapin> | but not chromium |
| 22:10 | <GPHemsley> | hmm |
| 22:10 | <GPHemsley> | so I guess Gecko looks for the semicolon to begin percent-decoding? |
| 22:11 | <SimonSapin> | is any MIME parameter other than charset actually used on the web? |
| 22:11 | <GPHemsley> | using %2C instead of the comma sends the text to search |
| 22:12 | <GPHemsley> | in Firefox |
| 22:12 | <GPHemsley> | SimonSapin: Well, audio/video types may use codecs= |
| 22:12 | <GPHemsley> | plus base64 |
| 22:12 | <SimonSapin> | base64 is special in data: not sure it counts as a parameter |
| 22:12 | <GPHemsley> | and I think there are a few obscure text/plain parameters |
| 22:13 | <GPHemsley> | SimonSapin: In what way doesn't it? |
| 22:13 | <SimonSapin> | no = sign and no value |
| 22:13 | <GPHemsley> | oh, hmm |
| 22:13 | <SimonSapin> | appears separately in the rfc2397 grammar |
| 22:13 | <GPHemsley> | didn't realize the MIME RFC doesn't allow an optional value |
| 22:14 | <SimonSapin> | “The ";base64" extension is distinguishable from a content-type parameter by the fact that it doesn't have a following "=" sign.” |
| 22:14 | <GPHemsley> | and neither does HTTP |
| 22:14 | <heycam> | Hixie, here now |
| 22:14 | <GPHemsley> | I was writing the algorithm taking it for granted that it was similar to URL parameters |
| 22:15 | GPHemsley | wonders if that would be a big deal. |
| 22:15 | <GPHemsley> | SimonSapin: What if you added an arbitrary value to a base64 parameter? |
| 22:15 | <GPHemsley> | Does it still work? |
| 22:16 | <SimonSapin> | then it’s a parameter, not a base64 marker |
| 22:16 | <GPHemsley> | SimonSapin: Is that a yes or a no? :P |
| 22:16 | <SimonSapin> | the content is not decoded as base64 |
| 22:16 | <GPHemsley> | hmm |
| 22:16 | <GPHemsley> | interoperably? |
| 22:16 | <SimonSapin> | but if you had an API to get the map of all parameters, you’d find the value there |
| 22:17 | <SimonSapin> | don’t know, but that is one point where the RFC is pretty clear |
| 22:17 | <SimonSapin> | data:text/plain;base64=a,ZmFpbA== |
| 22:17 | <GPHemsley> | the way I was writing the algorithm you'd get parameters = { 'charset': 'utf-8', 'base64': null } |
| 22:18 | <SimonSapin> | I think that’s wrong :p |
| 22:18 | <GPHemsley> | hmm... Safari decodes it to "fail" |
| 22:18 | <GPHemsley> | Firefox, Chrome, and Opera do not |
| 22:19 | <GPHemsley> | but that's OK... my algorithm still allows for that |
| 22:19 | <GPHemsley> | because data:text/plain;base64=,ZmFpbA== will give { 'base64': '' }} |
| 22:19 | <GPHemsley> | -} |
| 22:19 | <GPHemsley> | so you can distinguish between null and '' |
| 22:20 | <SimonSapin> | without the = sign it’s invalid in HTTP or MIME |
| 22:21 | <GPHemsley> | and the behavior is the same |
| 22:21 | <GPHemsley> | s/and/but/ |
| 22:21 | <SimonSapin> | I don’t know what the error handling is, though |
| 22:22 | <GPHemsley> | I'll continue writing the algorithm as I was, and then you can sort it out |
| 22:22 | <GPHemsley> | I imagine it'll be up to us to determine the error handling |
| 22:24 | <GPHemsley> | so... is it just me, or does RFC 2045 not actually define quoted-string? |
| 22:24 | <GPHemsley> | oh, maybe it's in RFC 822 |
| 22:25 | <GPHemsley> | ah, yeah |
| 22:26 | <GPHemsley> | OK, so a quoted-string uses \" include a quotation mark, and \\ to include a backslash |
| 22:31 | <TabAtkins> | annevk: Oh yeah, regarding variadic URLQuery#set, yeah, it replaces instances that already exist. If there are leftover things in the arg list, it appends to the end. If there are leftover items in the URLQuery, it deletes them. |
| 22:32 | <annevk> | TabAtkins: oh it deletes too? |
| 22:32 | <TabAtkins> | I figure that set() is always saying "screw you, use exactly these values now". |
| 22:32 | <annevk> | TabAtkins: so set("name") would be the same as delete("name")? |
| 22:32 | <TabAtkins> | So if you start with ?a=1&a=2&a=3, then say set('a',4), you'll have only a single 'a' value in the map. |
| 22:33 | <TabAtkins> | Or, to be more elaborate: |
| 22:34 | <TabAtkins> | Start with ?a=1&b=1&a=2&c=1&a=3. Call u.set('a', 4, 5), then serialize. You'll get ?a=4&b=1&a=5&c=1 |
| 22:34 | <TabAtkins> | (Losing the third 'a' key that was originally in the query.) |
| 22:35 | <TabAtkins> | And similarly, if you start with ?a=1&b=1, then call u.set('a', 2, 3), you'll get ?a=2&b=1&a=3. |
| 22:36 | <annevk> | Sure, that's pretty basic, I'm more interested in my question above. |
| 22:37 | <annevk> | Set currently does not delete so I guess we'd have to change that if we want to remain forward compatible... |
| 22:37 | <TabAtkins> | I just answered your question above, if I understood your question correctly. |
| 22:38 | <TabAtkins> | I thought the point of set() was that it overrode whatever existed in the url already, but maintained relative ordering when it could. |
| 22:45 | <Hixie> | heycam: i cc'ed you on e-mail |
| 22:45 | <heycam> | Hixie, cool, replied I assume. |
| 22:47 | <annevk> | TabAtkins: my question in particular was whether set(x) is the same as delete(x) because of the way variadics are defined |
| 22:47 | <annevk> | TabAtkins: heycam can correct me but a variadic requires zero or more values as I understand it |
| 22:48 | <heycam> | that's right |
| 22:48 | <annevk> | TabAtkins: we could of course make the argument set(DOMString, DOMString, DOMString...) or some such |
| 22:48 | <TabAtkins> | annevk: Oh! Now I get it! |
| 22:48 | <TabAtkins> | Yes, I'd require set() to have at least one "value". |
| 22:48 | <TabAtkins> | annevk: I wasn't parsing your question right before. |
| 22:49 | <TabAtkins> | It doesn't make sense to even call set() without at least one value to assign to the key. |
| 22:50 | <annevk> | heycam: why don't we do one or more and optional variadic for zero or more? |
| 22:51 | <heycam> | annevk, was just following how other languages do it |
| 23:03 | <TabAtkins> | annevk: Regarding the "return this" decision, Rick is responding adequately in anothr es-discuss thread titled "(Map|Set|WeakMap)#set() returns `this` ?". |
| 23:03 | <TabAtkins> | The answer to the "why not delete()?" part of your question is just "baby steps". Rick expects to resolve on that change too. |
| 23:03 | <TabAtkins> | (And it has equal use-cases to set() returning this.) |
| 23:03 | <annevk> | I'm not on es-discuss |
| 23:03 | <TabAtkins> | Let me link you, then. |
| 23:04 | <annevk> | but I'll take a look tomorrow or so |
| 23:04 | <TabAtkins> | Starts here: https://mail.mozilla.org/pipermail/es-discuss/2012-December/026811.html |
| 23:14 | <TabAtkins> | annevk: Yo, regarding urls. http://dev.w3.org/csswg/css3-values/#urls can we refer to something better than RFC3986 now? |
| 23:14 | <TabAtkins> | We have two refs - one to the syntax of urls and escapes, and one to the absolutization of relative urls. |
| 23:15 | <TabAtkins> | Basically, is the URL spec good enough now for us to point to i? |
| 23:16 | <annevk> | TabAtkins: It defines all the infrastructure, may contain bugs, and does not deal with IDNA yet because nobody has decided how that should work. |
| 23:16 | <annevk> | TabAtkins: I'm all for referencing it myself, so people complain and yell at me and I can fix more bugs. |
| 23:16 | <TabAtkins> | Hah. |
| 23:17 | <annevk> | It defines syntax (called URL) and defines parsing #concept-url-parser and the result of parsing a URL is a parsed URL which you can pass to "fetch" (which is a concept that needs a bit more elaboration, it's scheduled to be worked on at some point) |
| 23:18 | <TabAtkins> | I'm not worrying about CSS fetch yet. |
| 23:18 | <TabAtkins> | I think I can just refer to #concept-url. |
| 23:22 | <fantasai> | annevk: Looking at that... I think that parsing and absolutizing a URL shouldn't be conflated. They're really two separate things, even if you can do them in a single pass. |
| 23:22 | <fantasai> | annevk: Should be able to parse in a relative URL, understand it, and reserialize it without changing its relativeness |
| 23:23 | <annevk> | fantasai: file a bug? be sure to list use cases; "should be able to" does not count :) |
| 23:24 | <TabAtkins> | Supporting CSS is a use-case - specified values of urls are whatever you put in, parsed, but computed values are absolutized. |
| 23:25 | <fantasai> | Also, an editor would want to be able to parse and understand URLs, but not absolutize everything in the document when they reserialize it out |
| 23:30 | <annevk> | TabAtkins: right, that's supported |
| 23:30 | <annevk> | fantasai: editing typically requires its own parser anyway, because you would not want to lowercase host names and such either |
| 23:31 | <annevk> | fantasai: same e.g. for editing CSS; you wouldn't want your editor to drop -webkit-ballgame |
| 23:34 | <TabAtkins> | Parsing without dropping unknown values doesn't require anything fancy. You still want to resolve urls as you normally do. |
| 23:35 | <TabAtkins> | (You just follow the Syntax spec and don't drop anything for being unrecognized.) |
| 23:38 | <annevk> | TabAtkins: have you looked at the URL parsers in browsers? |
| 23:38 | <TabAtkins> | Nope! |
| 23:38 | <annevk> | TabAtkins: my spec is not based on fiction :) |
| 23:39 | <TabAtkins> | I'm not sure what you mean. |
| 23:41 | <annevk> | what I mean is that the model is parseURL(input, base) -> parsed URL |
| 23:41 | <annevk> | or failure* |
| 23:41 | <annevk> | anyway, bedtime |
| 23:42 | <annevk> | nn |
| 23:45 | <PaKScripT> | Hiya fellas.. seen the channel on one of the 'tutorials' for html 5/javascript apis. |