| 09:46 | <odinho> | Grrr. Mercurial. Hate, hate. |
| 09:46 | <odinho> | Y U NO rebase? :| |
| 09:47 | <hsivonen_> | odinho: it has rebase, but last I heard, the advice was not to use it because of a catastrophic bug |
| 09:47 | <hsivonen> | I’m rather unhappy about the impact of ambiguous ampersand checking |
| 09:51 | <zcorpan> | hsivonen: impact being that less cases are flagged by the validator? |
| 09:55 | <odinho> | Finally able to push. Phew. hg always manages to make me grumpy. Have to do something fun now. Lunch I guess :P |
| 09:55 | <hsivonen> | zcorpan: the impact being having to touch the most brittle part of the tokenizer code |
| 09:55 | <zcorpan> | hsivonen: ah |
| 10:23 | <zcorpan> | TabAtkins: re https://bugs.webkit.org/show_bug.cgi?id=39140 doesn't webkit already use a different parser for html colors? |
| 12:37 | <darobin> | so for a redirect on a DELETE, Firefox prompts (and does it if you accept the prompt), Safari and Opera automatically fail (they send a GET to the redirect URL), Chrome automatically redirects as a DELETE |
| 12:37 | darobin | wonders if anyone is concerned with HTTP interop |
| 12:49 | karlcow | is not concerned but interested by HTTP interop ;) |
| 13:08 | <zcorpan> | darobin: have a TC? |
| 13:09 | <zcorpan> | darobin: is this xhr? |
| 13:09 | <darobin> | zcorpan: yup, gisting TC, gimme a sec |
| 13:11 | <darobin> | zcorpan: https://gist.github.com/3852447 |
| 13:15 | <darobin> | zcorpan: note that when I say "fail" above, I mean "fail against what I'd like them to do" — it may well be that some exegesis of the HTTP spec could construe that as the correct behaviour |
| 13:16 | <zcorpan> | xhr spec has a note saying "Note: HTTP places requirements on the user agent regarding the preservation of the request method and request entity body during redirects, and also requires end users to be notified of certain kinds of automatic redirections." |
| 13:17 | <zcorpan> | http says "The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD." |
| 13:18 | <zcorpan> | (for 3xx) |
| 13:18 | <zcorpan> | for 302, "If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued." |
| 13:20 | <karlcow> | http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-7.4 |
| 13:20 | <zcorpan> | same with 307 |
| 13:24 | <zcorpan> | well, after reading the spec, i have no idea what's supposed to happen |
| 13:24 | <darobin> | zcorpan: that's pretty much where I ended up after trying to read it :) |
| 13:25 | <darobin> | a strict reading might give Firefox as the one right way, but frankly prompting people to accept a redirect for an XHR request is UI madness |
| 13:27 | <zcorpan> | http://trac.tools.ietf.org/wg/httpbis/trac/report/9 seems to be the open non-editorial issues |
| 13:29 | <zcorpan> | i guess filing an issue "actually define what is supposed to happen" is not likely to do the trick |
| 13:30 | <zcorpan> | darobin: browsers could refuse the redirect without prompting |
| 13:30 | <darobin> | zcorpan: that's what Opera and Safari do, but it's not really all that useful either |
| 13:31 | <zcorpan> | darobin: i thought you said they change to GET |
| 13:31 | <zcorpan> | that's not the same as not redirecting |
| 13:31 | <darobin> | oh, yes, you actually not do anything — yes, indeed |
| 13:32 | <darobin> | in Firefox if you cancel the prompt that's what it does, you get the redirect response directly in XHR |
| 13:32 | <zcorpan> | but i don't know what kind of web compat impact that would have |
| 13:32 | <karlcow> | If the |
| 13:32 | <karlcow> | required action involves a subsequent HTTP request, it MAY be carried |
| 13:32 | <karlcow> | out by the user agent without interaction with the user if and only |
| 13:32 | <karlcow> | if the method used in the second request is known to be "safe", as |
| 13:32 | <karlcow> | defined in Section 5.2.1. |
| 13:32 | <karlcow> | The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe. |
| 13:32 | <karlcow> | DELETE is not safe |
| 13:32 | <darobin> | zcorpan: presumably none given that no two browsers do the same thing |
| 13:33 | <zcorpan> | darobin: all browsers allow following the redirect in some way (opera/safari get the method wrong, firefox prompts first) |
| 13:34 | <zcorpan> | (dunno about ie) |
| 13:34 | <darobin> | zcorpan: right, but I doubt anyone relies on this — though I wouldn't be shocked otherwise |
| 13:34 | <darobin> | have been too lazy to test IE, might fire up the VM later |
| 13:34 | <karlcow> | so basically for XHR it would mean a piece of UI for asking the user which I guess would make some designers go ballistic about the ugly modal window, but that's another story |
| 13:35 | <darobin> | karlcow: FF prompts on XHR — it's damned stupid |
| 13:35 | <karlcow> | darobin: for all methods |
| 13:35 | <karlcow> | or only unsafe methods |
| 13:35 | <darobin> | only for unsafe |
| 13:35 | <karlcow> | so I'm glad it does |
| 13:35 | <darobin> | well, I only tested DELETE here but I know it doesn't prompt on GET redirect |
| 13:36 | <karlcow> | There could be nasty side effects. |
| 13:36 | <darobin> | karlcow: except that that requirement is built on the assumption that the UA's user knows they're issuing a DELETE over HTTP — that's not the case here.... |
| 13:36 | <karlcow> | hmm? |
| 13:36 | <darobin> | I mean you click a little cross in a UI and you get a modal saying "This site is redirecting you, do you really want that?" |
| 13:37 | <darobin> | that's a guaranteed user "WTF???" |
| 13:37 | <karlcow> | So you mean the prompt is dumb. |
| 13:37 | <karlcow> | Not the fact that there is a prompt |
| 13:37 | <darobin> | there is no generic prompt that could make sense here |
| 13:37 | <zcorpan> | darobin: or worse, it happens at some random time and the user has no idea what's going on |
| 13:37 | <karlcow> | "the prompt message" I meant |
| 13:37 | <karlcow> | UX issue |
| 13:37 | <darobin> | zcorpan: well yeah, it could happen several ms later, after the UI has removed what's being deleted... |
| 13:38 | <zcorpan> | darobin: i mean the author could issue an XHR at any time without it being bound to something the user does |
| 13:38 | <darobin> | for XHR, given we're not in an interactive environment, I would expect either the script to have an option to say it knows what it's doing, or to just assume that by default |
| 13:38 | <darobin> | zcorpan: indeed, though that's unlikely for DELETE |
| 13:38 | <darobin> | but yes |
| 13:39 | <zcorpan> | this is the web we're talking about, nothing is unlikely :-P |
| 13:39 | <darobin> | heh, sure :) |
| 13:39 | <karlcow> | I guess there are two ways to deal with that. Forbid in browsers any unsafe redirections altogether. Always. |
| 13:39 | <karlcow> | Or have prose explaining that Browsers should be really explicit about the damages it might create. |
| 13:40 | <karlcow> | darobin: XHR, trusting the script is not a good idea. |
| 13:40 | <darobin> | karlcow: I would agree with you for stuff like <a href=foo.html method=DELETE> but in XHR I don't think interactive rules should apply |
| 13:40 | <karlcow> | think about POST which is unsafe too |
| 13:41 | <zcorpan> | this discussions seems moot unless someone's gonna write a spec :-) |
| 13:42 | <karlcow> | darobin: hmm… I think I still apply. I do not want to have a script kiddie doing something for me which is not safe. |
| 13:42 | <darobin> | I'll mull over making this defined for XHR — fixing HTTP is probably hopeless |
| 13:43 | <darobin> | karlcow: I'm not sure I can think of a useful attack scenario that 1) isn't blocked by SOP or 2) isn't already an attack anyway |
| 13:43 | karlcow | is looking for SOP acronym |
| 13:43 | <darobin> | same-origin policy |
| 13:44 | <darobin> | in any case I stumbled over this issue while coding for a project; writing a spec is unlikely to fix the issue within the project's time frame ;) |
| 13:44 | <karlcow> | heh |
| 13:54 | karlcow | wonders if IE and Chrome still support this https://htaccess.wordpress.com/2009/09/22/x-content-type-options-nosniff-header/ |
| 13:54 | <karlcow> | X-Content-Type-Options: nosniff |
| 14:06 | <darobin> | karlcow: wish I could send that header to my own nose |
| 14:07 | <karlcow> | :) |
| 16:20 | <TabAtkins> | zcorpan: Now it does, yes, because I fixed it. ^_^ We're now just waiting for someone to write the Color 4 module and actually specify 4/8 digit hex colors. |
| 17:28 | <rniwa> | a silly question. is a boolean attribute still considered true even if the value doesn't match its name? |
| 17:28 | <rniwa> | e.g. checked=true |
| 17:29 | <TabAtkins> | Yes. Booleans are true if they exist, regardless of value, and false if they dont'. |
| 17:30 | <TabAtkins> | Ie they use hasAttribute for true/falseness. |
| 17:30 | <rniwa> | TabAtkins: apparently the U.S. government doesn't know how to use them correctly |
| 17:30 | <rniwa> | :( |
| 17:30 | <TabAtkins> | Lots of people don't. |
| 17:30 | <rniwa> | TabAtkins: go to https://egov.uscis.gov/crisgwi/go?action=coa.Terms |
| 17:30 | <rniwa> | TabAtkins: Accept terms |
| 17:30 | <rniwa> | and click on "Yes, this change of address is not for a US Citizen" |
| 17:30 | <rniwa> | Ugh… "No,..." |
| 17:31 | <rniwa> | then all text fields that are NOT required, has required=true :( |
| 17:31 | <rniwa> | and Chrome thinks they're required and won't let me submit the form |
| 17:31 | <miketaylr> | i've tried to contact them for about 2 years to fix that |
| 17:31 | <rniwa> | miketaylr: maybe we need to fix the browser UI to ignore required fields in some cases? |
| 17:32 | <miketaylr> | rniwa: http://my.opera.com/miketaylr/blog/u-s-citizenship-and-immigration-services-change-of-address-bless-their-hearts |
| 17:32 | <TabAtkins> | rniwa: That's what your inspector is for. |
| 17:32 | <rniwa> | I mean… as ridiculous as it sounds, having to modify the page on Inspector just to omit my middle name, etc… was insanely annoying to say the least. |
| 17:32 | <rniwa> | TabAtkins: that's not an acceptable option for a lot of people. |
| 17:32 | <TabAtkins> | But required=true is just nonsense. If it was required=false and they were expecting it to not be required, that's a different story. |
| 17:32 | <rniwa> | TabAtkins: you can't expect an average user to be able to use this form. |
| 17:33 | <rniwa> | TabAtkins: they have "required=no" |
| 17:33 | <TabAtkins> | rniwa: No, I can't. They have a broken page. |
| 17:33 | <TabAtkins> | rniwa: Oh, you said required=true. |
| 17:33 | <rniwa> | TabAtkins: i mean… required=true is also bad. |
| 17:33 | <rniwa> | TabAtkins: required=true and required=no are the same thing |
| 17:33 | <TabAtkins> | Oh goddammit I just crashed chrome. |
| 17:33 | <rniwa> | TabAtkins: as far as HTML is concerned |
| 17:34 | <rniwa> | I guess I'm gonna just file a chromium bug about this :/ |
| 17:34 | <TabAtkins> | Yes, I know. That's what I said earlier. ^_^ |
| 17:34 | <miketaylr> | they *really* dont' want to fix that page |
| 17:34 | <TabAtkins> | Dude, I will shut down that bug. We should *not* go down the rabbit's path of trying to guess what retarded attribute values people try to put in. |
| 17:34 | <miketaylr> | "We cannot support Google Chrome for completing your Change of Address at this time. Change of Address is optimized to use Internet Explorer 6 and 7." |
| 17:35 | <TabAtkins> | That leads to supporting "false", "n", "no", "off", and more. |
| 17:35 | <rniwa> | :( |
| 17:35 | <rniwa> | TabAtkins: that's a terrible user experience. |
| 17:35 | <TabAtkins> | rniwa: I... agree? That's their fault. |
| 17:35 | <rniwa> | TabAtkins: so you're telling me that the correct way to deal with this is to abandon Chrome |
| 17:35 | <rniwa> | TabAtkins: and use IE? |
| 17:36 | <rniwa> | TabAtkins: I mean that's the only option for many users here. |
| 17:36 | <TabAtkins> | That's the right thing *for this page*, because they're complete fucking morons and don't know how to internet. |
| 17:36 | <rniwa> | TabAtkins: that's not an acceptable decision as far as I'm concerned. |
| 17:37 | <rniwa> | TabAtkins: all non-US citizens living in the U.S. needs to use this change. |
| 17:37 | <rniwa> | TabAtkins: that's in the order of millions |
| 17:37 | <TabAtkins> | rniwa: I don't think breaking our browser against the spec is the right answer to every single retardely-authored webpage. |
| 17:38 | <rniwa> | TabAtkins: what if this was youtube or yahoo.com? |
| 17:38 | <TabAtkins> | It's not even broken. It just means you ahve to fill in every field. |
| 17:38 | <rniwa> | TabAtkins: would you still say the same? |
| 17:38 | <TabAtkins> | It's not. |
| 17:38 | <rniwa> | anyway, i'm gonna stop talking about this with you |
| 17:38 | <rniwa> | it's not productive |
| 17:38 | <TabAtkins> | And if it were, it wouldn't be "optimized to use INternet Explorer 6 and 7" |
| 17:38 | <TabAtkins> | Hokay. |
| 21:27 | <annevk> | is licensing gonna be clarified for webplatform.org? |
| 21:27 | <annevk> | or am I not looking in the right place? |
| 21:27 | <annevk> | paul_irish: ^^ |
| 21:29 | <hober> | annevk: in "Half-day tasks" on http://docs.webplatform.org/wiki/WPD:Getting_Started it says "Content original to the site is licensed under a Creative Commons Attribution License (CC-BY 3.0) for maximum reusability." |
| 21:29 | <hober> | (It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'.) |
| 21:30 | <annevk> | heh |
| 21:30 | <annevk> | maximum would be public domain imo, but I guess that license works |
| 21:31 | <hober> | also, wat: http://docs.webplatform.org/wiki/html/elements/custom |
| 21:32 | <annevk> | well it originates from Microsoft |
| 21:32 | <Hixie> | when they say "original to the site" i presume they're excluding all of msdn which is all i came across |
| 21:32 | <Hixie> | (pretty bogus content, too) |
| 21:33 | <annevk> | hmm yeah, e.g. http://docs.webplatform.org/wiki/css/color/CSSOM_view |
| 21:33 | <annevk> | clearly alpha |
| 21:33 | <paul_irish> | yup |
| 21:33 | <paul_irish> | we did an automated import of MSDN docs and a lot of items are not exactly standard.. |
| 21:34 | <paul_irish> | so we need to flag those as proprietary |
| 21:34 | <annevk> | what's gonna happen to MDN? |
| 21:34 | <paul_irish> | https://hacks.mozilla.org/2012/10/welcoming-the-new-kid-web-platform-docs/ answers that best |
| 21:35 | <paul_irish> | there's a little bit of "wait and see" approach from some folks, others in moz want all future docs at WPD |
| 21:35 | <paul_irish> | so its a little complicated |
| 21:35 | <paul_irish> | but not bad in any way |
| 21:35 | <annevk> | ah shit, Mozilla did licensing wrong |
| 21:36 | <Hixie> | the agreement when you get an account is kinda weird, too. refers to "Contributions" with a capital C but doesn't define what those are. |
| 21:36 | <annevk> | thanks paul_irish! |
| 21:37 | <paul_irish> | yeah drop me a link on anything that looks totally whack or shouldnt belong and i'll file a ticket for people to look at it. |
| 21:38 | <Hixie> | http://docs.webplatform.org/wiki/html/elements/html_comment_data-type is basically entirely wrong at every level. :-) |
| 21:50 | <zewt> | can progressive jpegs please be removed from all jpeg compressors already |
| 21:51 | <zewt> | we're not on 300 baud modems and people keep using it by accident and they make my eyes bleed |
| 21:51 | <Hixie> | ew no |
| 21:51 | <Hixie> | more progressive please |
| 21:51 | <zewt> | "progressive jpeg" doesn't mean "progressive decompression" |
| 21:51 | <Hixie> | i wish every pic would start off as one pixel of colour and then 4 and then 16 and then 64 etc |
| 21:51 | <Hixie> | oh |
| 21:51 | <Hixie> | then nevermind |
| 21:52 | <zewt> | it's analogous to "interlaced" pngs |
| 21:52 | <zewt> | where you get a big hideous blurry blob first |
| 21:52 | <Hixie> | isn't that what i just said i wanted? |
| 21:53 | <zewt> | dunno, progressive decompression is just "don't wait for the whole image to decompress before showing it", which doesn't require that sort of ugliness |
| 21:53 | <TabAtkins> | Hixie: I'd be interested to see if delta-compressing *that* much would be worthwhile. |
| 21:53 | <Hixie> | i don't want the images to decompress like window shades |
| 21:53 | <Hixie> | TabAtkins: oh i'm sure it'd be negative compression ratio :-) |
| 21:53 | <zewt> | blurry images hurt my eyes |
| 21:53 | <Hixie> | TabAtkins: at least to do it actually as silly as i describe |
| 21:53 | <Hixie> | zewt: just seeing eyes is even worse |
| 21:54 | <zewt> | if it starts at a non-blurry resolution and goes up from there, maybe okay (eg. upgrading from regular resolution to retina, so to speak) |
| 21:54 | <Hixie> | "regular" is blurry |
| 21:54 | <zewt> | but progressive jpegs start as a big artifacty gross mess |
| 21:54 | <zewt> | (usually) |
| 22:01 | <jgraham> | paul_irish: Repeating what I already said to karlcow and miketaylr, I think at this point the actual content is so confusing that you should add a big "under construction" gif and (more seriously) add links to the "how we want the site structure to end up" pages to the front page |
| 22:02 | <jgraham> | It's not really possible to figure out how to help yet because all there is is a big mess of stuff an no obvious coherent structure that it is supposed to be tidied into |
| 22:20 | <paul_irish> | jgraham: haha so i totally lost the argument that we should put http://codepen.io/joshnh/pen/ohbHl on the site 5 days ago :) |
| 22:20 | <paul_irish> | jgraham: agreed about the IA. thanks for the feedback |
| 22:21 | <paul_irish> | ill start some convos on that |
| 22:26 | <say2joe> | @paul_irish … love the animated gif |
| 22:27 | <say2joe> | (rather the animated gif turned css) |
| 22:35 | <TabAtkins> | paul_irish: Out of curiosity, what was the point of doing the under-construction thing with CSS rather than a GIF? |
| 22:35 | <paul_irish> | "because", i think.. |
| 22:36 | <paul_irish> | turns out its smaller.. but only after gzip. |
| 22:36 | <TabAtkins> | Sounds legit. |
| 22:36 | <TabAtkins> | Likely slower to render, since we don't fast-path solid shadows yet. |
| 22:36 | <TabAtkins> | At least, in Chrome. |
| 22:46 | <Hixie> | http://codepen.io/joshnh/pen/ohbHl is seriously messed up |
| 22:47 | <say2joe> | @Hixie: too much coffee? |
| 22:48 | <annevk> | Hixie: using box-shadow or radial gradients via background to draw images is a thing now |
| 22:49 | <annevk> | Hixie: hopefully at some point the drawing primitives from SVG just move over so it gets less clunky |
| 22:49 | <annevk> | and then we can drop SVG :p |
| 22:49 | <annevk> | -> sleep |
| 22:50 | <Hixie> | i hope it'll go the way of using html tables for bitmaps... |
| 23:20 | <Hixie> | anyone know how many files are in web200904 ? |
| 23:24 | <Hixie> | about 600,000 apparently |
| 23:25 | <TabAtkins> | I think just count the number of nulls and divide by 3. |
| 23:25 | <Hixie> | i wonder what they've been up to since 2009 |
| 23:28 | <TabAtkins> | Crawling more internet, presumably. |
| 23:28 | <Hixie> | you'd think they'd have posted an update in the meantime |