| 00:28 | <Hixie> | smaug____: (continuing discussion from yesterday about disabling buttons) no script libraries either |
| 00:29 | <Hixie> | smaug____: i just disabled all the addons except firebug and it still happens |
| 00:29 | <Hixie> | smaug____: only in firerfox |
| 00:29 | <Hixie> | smaug____: and it's a whole bunch of different unrelated buttons, too |
| 00:29 | <Hixie> | smaug____: can't seem to work out how to reproduce it though |
| 00:37 | <smaug____> | Hixie: Haven't heard of any bug reports about disabled buttons |
| 00:37 | <Hixie> | smaug____: yeah me either |
| 00:37 | <Hixie> | it has me baffled |
| 00:39 | <zewt> | an unusually targetted virus? heh |
| 00:40 | <Hixie> | smaug____: seems like it's probably https://bugzilla.mozilla.org/show_bug.cgi?id=592665 and https://bugzilla.mozilla.org/show_bug.cgi?id=654072 |
| 00:45 | <smaug____> | Well, shift-reload doesn't keep form state |
| 00:46 | <smaug____> | Hixie: and you said shift-reload doesn't help |
| 00:46 | <smaug____> | so it is something new |
| 00:46 | <smaug____> | s/new/else/ |
| 00:47 | <Hixie> | i might be mistaken about that. it's hard to say since it's intermittent. |
| 00:47 | <Hixie> | and i only see it some time after i did theload |
| 00:47 | <zewt> | if you're never disabling elements in the first place, 654072 shouldn't be relevant, i think |
| 00:48 | <Hixie> | some buttons get disabled, just not the ones that are getting mysteriously disabled |
| 00:48 | Hixie | wouldn't consider a button's disabled state to be "form state", btw |
| 00:48 | <Hixie> | i recommend not restoring disabled state :-) |
| 00:48 | <zewt> | that's pretty much verbatim what i just typed out in a comment on that bug :) |
| 01:09 | <GPHemsley> | annevk: Heh. Just noticed you're on the CC list for the bug 716422 I just filed. :) |
| 01:13 | <zewt> | gar, firefox console autocomplete is aggravating |
| 01:14 | <zewt> | needs to be tricked into *not* autocompleting when unwanted, heh |
| 01:16 | GPHemsley | has the same problem with Gmail search. FTW. |
| 02:39 | <bencc> | how does a websocket server should respond to a CONNECT request? |
| 08:00 | <annevk> | GPHemsley: not sure what that bug is about :) |
| 08:01 | <annevk> | GPHemsley: ooh, now I remember again |
| 08:02 | <annevk> | mebibytes ftw |
| 10:12 | <Ms2ger> | People who hadn't noticed it yet may be interested in http://www.w3.org/community/w3process/ |
| 10:49 | <zcorpan> | "create small, clean, orthogonal specs" |
| 10:52 | <Ms2ger> | Clean specs? |
| 10:52 | <Ms2ger> | Let's outsource that to the XHTML2 WG |
| 11:30 | <hsivonen> | hmm. annevk isn't here. |
| 11:31 | <hsivonen> | it would be nice to make xhr.status say 200 for successful non-HTTP responses unless doing so breaks the Web |
| 11:32 | <Ms2ger> | Yeah, that's what I thought :) |
| 11:32 | <Ms2ger> | Also, Anne's off the grid from Wednesday |
| 11:33 | <hsivonen> | Ms2ger: oh ok. I was hoping to be able to report spec bugs via IRC log. |
| 13:43 | <annevk> | hsivonen: what does it report now for non-HTTP responses? |
| 13:44 | <annevk> | hsivonen: in general non-HTTP is not really thoroughly considered at the moment |
| 13:45 | <annevk> | hsivonen: my view is mostly that for non-HTTP protocols/schemes we should define how they work in an HTTP context because all APIs we have "assume" HTTP |
| 13:45 | <hsivonen> | annevk: reportedly, IE10 and Chrome say 200 while Opera and Firefox say 0 |
| 13:45 | <annevk> | like for disk loads? or are we talking ftp? |
| 13:45 | <hsivonen> | annevk: blob: was the scheme that was tested |
| 13:45 | <annevk> | aah |
| 13:46 | <annevk> | hsivonen: http://dev.w3.org/2006/webapi/FileAPI/#processingModel |
| 13:46 | <annevk> | blob URLs already follow the model I want people to use |
| 13:46 | <annevk> | as they have been recently added I got that semi-addressed (not entirely pleased with the level of detail on HTTP headers yet) |
| 13:46 | <hsivonen> | annevk: and, yet, Firefox and Opera get blob: wrong |
| 13:47 | <annevk> | there's only so much I can do :) |
| 13:52 | <hsivonen> | annevk: you could add some informative notes to XHR to remind people that non-HTTP protocols should define their mappings to HTTP and give enough information for implementors to fill in the blanks when specs for non-http[s]: schemes fail to do so |
| 13:52 | <annevk> | where would be the best place to put that? |
| 13:53 | <hsivonen> | annevk: in the definition for each affected API |
| 13:53 | <annevk> | hmm |
| 13:53 | <hsivonen> | annevk: the definition of status should talk about 200 and 500 |
| 13:53 | <hsivonen> | for example |
| 13:54 | <hsivonen> | and GetResponseHeader should talk about Content-Type |
| 13:54 | <annevk> | so status / statusText/ getResponseHeader / getAllResponseHeaders ? |
| 13:54 | <annevk> | well not just Content-Type, all headers are important |
| 13:57 | <annevk> | but this is also relevant to e.g. HTML |
| 13:57 | <annevk> | hmm |
| 14:01 | <hsivonen> | annevk: adding notes makes it a lot more likely that this gets implemented correctly |
| 14:02 | <annevk> | yeah I guess |
| 14:02 | <annevk> | it's just that I've tried to avoid redundancy in similar situations |
| 14:05 | <bencc> | does a websocket server need to handle HTTP CONNECT requests |
| 14:05 | <bencc> | or only a proxy needs to handle it if there is one? |
| 14:07 | <annevk> | doesn't the spec say? |
| 14:11 | <bencc> | annevk: http://tools.ietf.org/html/rfc6455#section-4.1 |
| 14:11 | <bencc> | it talks about the CONNECT request but I don't understand who should respond to it and how |
| 14:11 | <zewt> | _holy hell_ /that spec/ |
| 14:12 | <zewt> | what the hell are they thinking? |
| 14:12 | <bencc> | ? |
| 14:12 | <zewt> | To _Establish a WebSocket Connection_ |
| 14:12 | <zewt> | A client will need to |
| 14:12 | <zewt> | supply a /host/, /port/, /resource name/, and a /secure/ flag |
| 14:12 | <bencc> | zewt: I don't understand |
| 14:13 | <zewt> | ... someone might want to let them know that you can actually underline and italic with HTML |
| 14:14 | <Philip`> | zewt: Why is that relevant, when they're not writing HTML? |
| 14:14 | <zewt> | that's html. |
| 14:14 | <zewt> | terrible html, to be sure |
| 14:14 | <Philip`> | It's plain text auto-converted to HTML |
| 14:15 | <zewt> | i don't care about the authoring path (and I doubt anyone but the editor does) |
| 14:16 | <zewt> | (and surely they could convert those) |
| 14:16 | <Philip`> | I presume "let them know" was referring to the editor, who cares that they're only able to write plain text |
| 14:17 | <bencc> | what about the proxy? :) |
| 14:17 | <Philip`> | (as opposed to alerting the IETF people who make the decision to stick with plain text as the canonical spec format) |
| 14:19 | <annevk> | zewt: dude, all IETF specs are plain text |
| 14:19 | <annevk> | zewt: tools.ietf.org just provides a nicer view of them, the "actual" version is http://www.ietf.org/rfc/rfc6455.txt |
| 14:19 | <zewt> | they already have plenty of transforms; it'd pretty much be s/_(.?*)_/<u>\1</u>/g |
| 14:20 | <zewt> | (eg. section numbers become links) |
| 14:20 | <zewt> | (is that the right syntax for non-greedy matching? i always forget, since I don't use it much) |
| 14:21 | <annevk> | bencc: this is what the client sends: http://tools.ietf.org/html/rfc6455#section-1.3 |
| 14:21 | <annevk> | bencc: so that is what you need to deal with |
| 14:22 | <annevk> | zewt: dunno if that would work for all RFCs |
| 14:22 | <annevk> | zewt: the syntax in the WebSocket spec is not universal |
| 14:22 | <bencc> | annevk: what about this? CONNECT example.com:80 HTTP/1.1 |
| 14:22 | <annevk> | bencc: I think that's only for proxies |
| 14:22 | <zewt> | annevk: i'm just surprised that my already more or less zero confidence in the IETF being able to write readable specs managed to drop yet another notch; but I guess I shouldn't be surprised |
| 14:23 | <annevk> | bencc: are you writing client or server software? |
| 14:23 | <bencc> | annevk: server |
| 14:23 | <bencc> | most of the requests works but recently I'm getting CONNECT requests which I don't know how to handle |
| 14:23 | <bencc> | my server directly gets requests with a proxy like haproxy |
| 14:23 | <bencc> | but maybe there is a proxy between the client and my server |
| 14:24 | <bencc> | I'm using port 8080 |
| 14:24 | <Philip`> | zewt: .*? |
| 14:25 | <Philip`> | zewt: That'd be terrible when people write underscore_separated_names in their spec text |
| 14:25 | <annevk> | bencc: from my brief reading that sounds like a problem that's not your fault |
| 14:26 | <zewt> | it'd need adjustment for separators, etc |
| 14:26 | <Philip`> | At least if auto-linking makes a mistake, the reader can just ignore the link and it won't affect the interpretation of the text |
| 14:26 | <Philip`> | Removing _s and /s would be much more risky |
| 14:26 | <zewt> | (not going to try since I'm not actually interested in spending lots of time trying to convince the IETF to do something) |
| 14:26 | <bencc> | annevk: what do you mean and how should I handle it? |
| 14:27 | <annevk> | bencc: i.e. you should just conform to http://tools.ietf.org/html/rfc6455#section-4.2.1 and CONNECT does not so you should fail the request |
| 14:27 | <Velmont> | You don't have to kill the _'s either. can just do <u>_text_</u> and <em>/text</em> it helps with reading. |
| 14:27 | Philip` | thinks that would make it even uglier |
| 14:28 | <bencc> | annevk: what about 4.1 3? |
| 14:28 | <bencc> | annevk: "_Proxy Usage_: If the client is configured to use a proxy when.." |
| 14:29 | <zewt> | should you just handle CONNECT the same way a regular HTTP server would? (Apache returns 405 Method Not Allowed) |
| 14:30 | <zewt> | (aka I'm Not A Proxy) |
| 14:30 | <bencc> | what can cause a client to send me a CONNECT request with Connection Close header? |
| 14:30 | <annevk> | bencc: that's how clients are supposed to deal with proxies |
| 14:31 | <annevk> | servers != proxies |
| 14:31 | <bencc> | annevk: the proxy should handle this request without passing it to my server? |
| 14:31 | <annevk> | yes, the proxy is supposed to open a TCP connection to your server and let the client use that to connect to your server |
| 14:31 | <annevk> | as I understand it |
| 14:32 | <zewt> | yep |
| 14:32 | <bencc> | so this is a bug in FF or the proxy server? |
| 14:32 | <zewt> | it's probably something goofier than that; a proxy server that didn't swallow the CONNECT header would be totally unusable |
| 14:33 | <zewt> | unless FF with proxy+websocket is just broken (that'd be surprising, though) |
| 14:34 | <Ms2ger> | zewt, I believe that's a remnant from Hixie's HTML->plain text transformation, actually |
| 14:36 | <annevk> | bencc: I suppose it could be either |
| 14:36 | <zewt> | i think the IETF just hates people reading their specs and wants to give them headaches :P |
| 14:37 | <annevk> | bencc: both browsers and proxies are known to be pretty weird |
| 14:38 | <zewt> | i'm somewhat confused that this spec mentions HTTP proxy details at all |
| 14:38 | <zewt> | rather than ignoring it as a transparent detail at another layer |
| 14:38 | <annevk> | not really sure what the point of that is either |
| 14:39 | <annevk> | maybe because in this case only the initial connection is HTTP and the rest is not |
| 14:39 | <annevk> | the TLS-only WebSocket design was so much neater |
| 14:42 | <hsivonen> | does Web Socket work nicely with Apache and mod_jk these days? |
| 14:42 | <annevk> | jk? |
| 14:42 | <annevk> | just kidding? |
| 14:43 | <hsivonen> | annevk: I believe it's short for Jakarta |
| 14:43 | <zewt> | same thing I thought, heh |
| 14:43 | <hsivonen> | annevk: for connecting to a servlet container supposedly more efficiently than by proxying HTTP |
| 14:46 | <annevk> | hsivonen: thanks for dealing with the document.write bug btw |
| 14:46 | <hsivonen> | annevk: you're welcome |
| 14:46 | <zewt> | the "i ignore parts of the spec when i know better" one? |
| 14:46 | <annevk> | hsivonen: it seemed somewhat reasonable to at least consider it |
| 14:46 | <hsivonen> | zewt: that one |
| 14:50 | <annevk> | AryehGregor_: where does http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections state when the associated range becomes non-null? |
| 14:52 | <AryehGregor> | annevk, 1) addRange(), 2) "The user agent should allow the user to change the selection." |
| 14:53 | <AryehGregor> | The idea of "is initially null" is just that <!doctype html><script>alert(getSelection().rangeCount); alerts 0. |
| 14:53 | <AryehGregor> | This could probably be made clearer. |
| 14:53 | <AryehGregor> | It's supposed to be null until the user actually selects something, or script sets it. |
| 14:54 | <AryehGregor> | Basically, what the selection looks like after user interaction is entirely undefined. |
| 14:54 | <AryehGregor> | Probably at some point it would be good to define it -- e.g., if the user selects something and then that thing gets deleted, or the user clicks somewhere so the selection is cleared, does the range become null again? |
| 14:54 | <AryehGregor> | I'd think so. |
| 14:54 | <AryehGregor> | But it's not specified. |
| 14:55 | <AryehGregor> | . . . Does that answer your question? |
| 14:56 | <annevk> | I'm interested in case 2) |
| 14:56 | <annevk> | I think what was not clear to people is that changing the selection makes a Range object appear |
| 14:56 | <annevk> | so maybe that should be explicit |
| 14:57 | <AryehGregor> | Would you like to file a bug? |
| 14:57 | <annevk> | sure |
| 14:57 | <AryehGregor> | Right now I'm working on transforms stuff. I'll probably return to the editing spec for a while once I'm done with that. |
| 14:57 | <annevk> | k |
| 14:57 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470 |
| 15:00 | <AryehGregor> | Is there a Bugzilla component for CSSOM View, or just CSSOM? |
| 15:01 | <zcorpan> | MikeSmith: ^ |
| 15:01 | <MikeSmith> | just for CSSOM |
| 15:01 | <MikeSmith> | I can create another one if you want |
| 15:01 | <AryehGregor> | I've been told CSSOM View currently doesn't have an editor, so . . . |
| 15:01 | <annevk> | I'd first coordinate with the editors |
| 15:02 | <zcorpan> | Nobody, is it OK if we create a bugzilla component? |
| 15:03 | <annevk> | euhm |
| 15:03 | <annevk> | didn't Glenn Adams sign up for both? |
| 15:03 | <annevk> | and Shane Stephens? |
| 15:03 | AryehGregor | doesn't know, only knows it still says you're the editor but you said you're not |
| 15:03 | <AryehGregor> | I assume that if no one has even bothered changing the editor in the spec, it's probably not very actively maintained . . . |
| 15:04 | <annevk> | the day I resigned from the CSS WG I was told someone was taking over so I assumed that would be immediate |
| 15:04 | <annevk> | often I assume wrongly in new scenarios |
| 15:05 | <AryehGregor> | Maybe I'll volunteer to edit CSSOM for a while. CSSOM interop is horrifyingly bad. |
| 15:05 | <zcorpan> | maybe they are responsible but haven't made any changes yet so didn't feel inclined to update the "editor" field |
| 15:05 | <AryehGregor> | And it's extremely frustrating sometimes. |
| 15:05 | <AryehGregor> | I had to spend lots of time hacking around it in my editing commands implementation. |
| 15:05 | <annevk> | Glenn explicitly asked me about the editor field weeks ago |
| 15:05 | <Ms2ger> | Enjoy dealing with The WG :) |
| 15:06 | <AryehGregor> | Is the CSSWG a pain to deal with? |
| 15:06 | <annevk> | it wasn't for me |
| 15:07 | <AryehGregor> | So far I haven't noticed it being a pain either. |
| 15:07 | <annevk> | I meant that in a different way; it seemed most people had different goals |
| 15:08 | <annevk> | to really fix the CSSOM, you have to fix the way the CSS model is defined |
| 15:08 | <AryehGregor> | How so? |
| 15:08 | <annevk> | because it's an API for the model |
| 15:09 | <annevk> | in theory defining an API is simple, you just say "return this bit from the model" |
| 15:09 | <AryehGregor> | What parts of the model aren't defined adequately? |
| 15:10 | <annevk> | but here you have to define some transformation on the model and return that, while not always being able to usefully reference the model |
| 15:10 | <annevk> | but maybe I was doing it wrong |
| 15:10 | <AryehGregor> | TBH, a lot of the stuff that bugged me was things like style="font-weight: bold" vs. style="font-weight: bold; " or such. That should be fixable without much trouble. |
| 15:10 | <annevk> | well e.g. the box model offset*/client/scroll* attributes |
| 15:10 | <AryehGregor> | Hmm, right. |
| 15:11 | <annevk> | property serialization is indeed something that needs fixing, but also depends on the model |
| 15:11 | <annevk> | e.g. is the model that bold becomes 600, or does it stay bold, etc. |
| 15:11 | <annevk> | I pointed this out a few times, but it was basically up to me alone to fix the model |
| 15:12 | <annevk> | and then push that through the WG somehow |
| 15:12 | <annevk> | I didn't really want to get into that |
| 15:12 | <annevk> | I was hoping more people would be on board and see the problem, but it didn't work out that way |
| 15:13 | <annevk> | as far as dealing with the CSS WG goes, I guess the issue is mostly that you can only get people's attention at a F2F meeting and the discussion is not always focused there |
| 15:13 | hsivonen | learns about https://developer.mozilla.org/index.php?title=en/application%2F%2Fhttp-index-format_specification |
| 15:14 | <hsivonen> | https://developer.mozilla.org/en/application%2F%2Fhttp-index-format_specification rather |
| 15:24 | <zcorpan> | another application of the html parser? |
| 15:54 | <matjas> | annevk: “doing that just that” |
| 15:55 | <matjas> | s/honers/honors/ |
| 15:55 | <annevk> | yay for matjas |
| 15:56 | <annevk> | new weekly everyone: http://blog.whatwg.org/happy-2012 |
| 16:02 | <annevk> | ooh, now 7,129 subscribers according to Google Reader |
| 16:10 | <AryehGregor> | Yay, I found a point where there's a notable lack of interop. |
| 16:11 | <AryehGregor> | For transform and transform-origin, percentages are supposed to be relative to the border box. |
| 16:11 | <AryehGregor> | Everyone does the actual transforms that way, but for getComputedStyle(), IE treats percentages as relative to the padding box, and Chrome 17 dev relative to the content box. |
| 16:14 | <annevk> | if you've been working on this for a while that's surprising |
| 16:14 | <AryehGregor> | Yeah, interop is quite good. |
| 16:14 | <AryehGregor> | I've heard 3D transforms are worse. |
| 16:15 | <AryehGregor> | Of course, transitions and animations are probably a mess, but those are going to be a real pain to test anyway . . . |
| 16:37 | <dglazkov> | good morning, Whatwg! |
| 16:38 | <AryehGregor> | So, so far there's perfect interop on the visual results of 2D transforms, except that Opera sometimes slightly exceeds my 1.5px error margin for rotations. |
| 16:38 | <AryehGregor> | The only lack of interop so far is computed values. |
| 16:38 | <GPHemsley> | annevk: Agreed. |
| 16:39 | <AryehGregor> | But I'm only written a 487-line test file so far. |
| 16:39 | <AryehGregor> | I'm sure I'll find something. |
| 16:39 | <annevk> | GPHemsley: ah, we're back to conversing about mebibytes :) |
| 16:40 | annevk | has been trying to write something coherent about XML5 |
| 16:40 | <GPHemsley> | annevk: Yup. Gotta keep you on your toes. :) |
| 16:40 | <annevk> | Introduction: XML is hard. |
| 17:04 | <AryehGregor> | Now I found an Opera bug, but it's really table-related, not transform-related: height on a table seems to control the height of the border box, not the content box. |
| 17:07 | <jgraham> | AryehGregor: Seems to be already bugged |
| 17:08 | <AryehGregor> | k. |
| 17:13 | <gsnedders> | I presume WebKit doesn't do that anymore, then? |
| 17:13 | <gsnedders> | WebKit used the quirks box-model for tables for years |
| 17:15 | <AryehGregor> | Doesn't seem to. |
| 17:16 | <gsnedders> | That bug goes back to when I did WebKit stuff, so yeah. |
| 17:16 | <gsnedders> | Though it goes all the way back to KHTML. |
| 18:45 | <Ms2ger> | Why's this forums guy going on about Mosaic? |
| 20:22 | <annevk> | http://www.reddit.com/r/videos/comments/o98ty/pow_blinking_in_morse_code_to_spell_torture/c3ff18w reading about history on reddit is so much more fun |
| 22:59 | <Hixie> | of all the features i've specced over the years, none has had as many people trying to use it for unexpected purposes than appcache |
| 22:59 | <Hixie> | on www-html, someone is asking for how to embed a manifest inside an HTML file because they want to make their app a one-file app. |
| 22:59 | <Hixie> | ...what? |
| 23:10 | <Hixie> | is Smylers ever on IRC? |
| 23:48 | <Hixie> | ooo, there's a CSS Product now in bugzilla |
| 23:48 | <Hixie> | is this new? |
| 23:48 | <Hixie> | looks like it's new as of a few months ago |
| 23:49 | <Hixie> | good to know |
| 23:59 | <MikeSmith> | Hixie: it was there for a while but we added some more components to it |
| 23:59 | <MikeSmith> | if you want any other components added, lemme know |