| 08:07 | <krijnh> | <-- |
| 08:07 | <krijnh> | <-- back even |
| 08:38 | <zcorpan> | LC seems like even more bureaucracy |
| 09:23 | <roc> | U+2028/2029 are good for causing crashes in some platform text shapers too |
| 09:35 | <b4z81> | hi |
| 15:12 | <hsivonen> | does someone maintain a summary of Web Socket changes since -75? |
| 15:14 | <zcorpan> | -75? |
| 15:14 | <hsivonen> | zcorpan: what was the last one that was basically Hixie's creation? |
| 15:15 | <hsivonen> | was it -76? |
| 15:15 | <zcorpan> | yeah |
| 15:15 | <hsivonen> | I can't remember how much IETFness was in 76 vs. 75 |
| 15:15 | <zcorpan> | actually hixie's latest is called "-latest" and didn't go into ietf |
| 15:15 | <hsivonen> | -latest sounds more Living than numbered snapshots :-) |
| 15:16 | <zcorpan> | which had changed framing and a few other fixes (subprotocol negotiation comes to mind) |
| 15:16 | <zcorpan> | but -76 was what got implemented, basically |
| 15:16 | <hsivonen> | ok, so is there a summary of the delta between -76 and whatever it is that's being implemented now? |
| 15:17 | <zcorpan> | (opera has a few things from -latest that we had whined about and implemented before hixie got around to fixing the spec) |
| 15:17 | <zcorpan> | not that i'm aware of |
| 15:17 | <zcorpan> | i would summarize it as follows: everything is changed |
| 15:18 | <hsivonen> | zcorpan: ok. thanks. |
| 15:18 | <jgraham> | That's what I was going to say :) |
| 15:18 | <jgraham> | It is basically unrecognisable |
| 15:18 | <hsivonen> | zcorpan: did the IETF add or remove features in addition to changing how the old features mapped to bits on the wire? |
| 15:19 | <zcorpan> | added "extensibility", binary support, compression support |
| 15:19 | <zcorpan> | actually i don't recall the state of compression |
| 15:19 | <zcorpan> | might be taken out currently |
| 15:20 | <zcorpan> | also made lots of details undefined |
| 15:21 | <zcorpan> | like error handling |
| 15:21 | <zcorpan> | see http://www.ietf.org/mail-archive/web/hybi/current/msg07063.html |
| 15:24 | <hsivonen> | zcorpan: leaving error handling details undefined is seriously uncool. Sad to learn that that happened. :-( |
| 15:24 | <hsivonen> | zcorpan: what does extensibility do? |
| 15:25 | <zcorpan> | hsivonen: the framing has reserved bits for anyone to claim special behavior for, aiui |
| 15:25 | <zcorpan> | hsivonen: and there's a header to enable the extension or something |
| 15:25 | <zcorpan> | although extensions do not need to use the reserved bits (e.g. compression doesn't) |
| 15:27 | <zcorpan> | hsivonen: please complain on hybi about undefined error handling |
| 15:27 | <zcorpan> | hsivonen: as far as i can tell everyone else on hybi seems to think it's cool |
| 15:27 | <zcorpan> | more or less |
| 15:32 | <zcorpan> | reminds me that i still need to review the newest spec changes |
| 15:36 | <zcorpan> | hsivonen: oh also close frames have status codes |
| 15:52 | hsivonen | tries not to get involved in hybi |
| 15:53 | <zcorpan> | hsivonen: i don't blame you :-) |
| 16:16 | <Workshiva> | zcorpan: But I hope someone is getting involved, so it doesn't just run wild |
| 16:22 | <jgraham> | Workshiva: That policy failed |
| 16:23 | <jgraham> | AFAICT the only browser people involve are Ian Fette from Google and Patrick McManus from Mozilla |
| 16:24 | <jgraham> | Notably these are not the people who have been involved with WHATWG / recent W3C work |
| 16:30 | <Workshiva> | So the plan is just to hope it doesn't run too wild? :) |
| 16:31 | <jgraham> | I don't think ther is a plan |
| 16:31 | <jgraham> | +i |
| 16:32 | <zcorpan> | yeah i don't know what to do really when it comes to updating our impl |
| 16:32 | <zcorpan> | i guess i will need to reverse engineer mozilla and chrome |
| 16:33 | <zcorpan> | yay for having a spec |
| 16:35 | <zcorpan> | i also hope somebody will push for simplifying the extension mechanism |
| 16:36 | <zcorpan> | or removing it |
| 19:08 | <karlcow> | "No matter how good the MSFT rumor/news, this presentation is pretty painful thus far. #OSBC" http://twitter.com/dr138/status/70189401380093952 |
| 22:05 | <AryehGregor> | Wait, localStorage only stores strings? That's confusing. |
| 22:06 | AryehGregor | just ran into that in the context of the fact that Boolean(String(false)) == true |
| 22:09 | <Philip`> | I thought it stored structured clones (at least in theory)? |
| 22:10 | <AryehGregor> | Does it? It seems like when I put in a boolean, I get back a string. |
| 22:10 | <Philip`> | "Values can be any data type supported by the structured clone algorithm." |
| 22:11 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/994 |
| 22:11 | <AryehGregor> | log: string |
| 22:12 | <AryehGregor> | In all four engines. |
| 22:12 | <Philip`> | (and that algorithm should pass primitive values unchanged) |
| 22:12 | <Philip`> | Don't know if implementations do that, though |
| 22:12 | <bga_> | json everywhere |
| 22:14 | <bga_> | localStorage['a'] = '1\02' :( |
| 22:14 | <TabAtkins> | Theoretically, it does structured clones. In reality, it's all strings for now. |
| 22:14 | <bga_> | we can not store \x00-\xFF => we can not store binary data |
| 22:15 | <bga_> | asciiz was bad invention |
| 22:16 | <bga_> | window.name also can not contains \0 |
| 22:16 | <zewt> | localStorage is structured clone but I don't think it's widely implemented? |
| 22:17 | <zewt> | many apis seem to be in that state currently |
| 22:18 | <zewt> | from bugzilla spam it looks like they just fixed History doing that in FF |
| 22:18 | <zewt> | would be very nice to be able to store File references in history; don't know if that actually works yet |
| 22:19 | <TabAtkins> | bga_: Just store binares in base64 instead. |
| 22:19 | <bga_> | TabAtkins can you force implementation to store string as len(4 bytes) + content instead content + \0 ? |
| 22:19 | <bga_> | TabAtkins no |
| 22:19 | <zewt> | base64 utf-16, heh |
| 22:19 | <bga_> | i dont want overhead |
| 22:20 | <TabAtkins> | bga_: Then shrug. |
| 22:27 | <Hixie> | lordy, window.external interop is poor |
| 22:48 | <jamesr> | Hixie: yt? |
| 22:48 | <Hixie> | yeah |
| 22:48 | <Hixie> | sup |
| 22:48 | <jamesr> | so about the canvas AX stuff |
| 22:49 | <jamesr> | is this the use case in mind: http://webstuff.nfshost.com/examples/canvas_form.html ? |
| 22:49 | <Hixie> | no |
| 22:49 | <Hixie> | it's more about buttons and list boxes |
| 22:49 | <Hixie> | text editors in canvas don't make sense |
| 22:49 | <jamesr> | are they different? |
| 22:50 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/complete.html#best-practices |
| 22:50 | <erlehmann> | what |
| 22:50 | <erlehmann> | madness |
| 22:50 | <erlehmann> | jamesr, who created this stuff and whyyyyyyyyyyyy? |
| 22:50 | <jamesr> | lemme make a version with buttons and list boxes, then |
| 22:51 | <jamesr> | erlehmann: i made that page to try to figure out wtf people are talking about with this stuff |
| 22:51 | <jamesr> | because the text editing case is pretty dumb |
| 22:51 | <mpilgrim> | all roads lead to bespin |
| 22:51 | <jamesr> | not even bespin uses a canvas any more |
| 22:52 | <mpilgrim> | doesn't matter, that's what kicked off the frenzy a few years ago |
| 22:52 | <mpilgrim> | they've been going non-stop ever since |
| 22:52 | <mpilgrim> | srsly |
| 22:52 | <erlehmann> | i have never seen something like this before, srsly |
| 22:52 | mpilgrim | shrugs |
| 22:53 | <jamesr> | Hixie: what do you mean by list box? <select> ? |
| 22:54 | <jamesr> | select elements are fairly magical |
| 22:54 | <Hixie> | or radio buttons, yeah |
| 22:55 | <Hixie> | i just mean the general concept |
| 22:55 | <jamesr> | there's no way for a canvas to closely emulate a pop-out <select> |
| 22:55 | <Hixie> | sure |
| 22:55 | <Hixie> | i don't mean close emulation |
| 22:56 | <Hixie> | i just mean a selection mechanism |
| 22:56 | <jamesr> | gotcha |
| 22:57 | <Hixie> | basically the extent to which interactivity makes sense on a canvas, excluding cases that only make sense on a canvas e.g. gameplay or graphic manipulation, is limited to really simple stuff like buttons, menus, toggling ui, that kind of thing |
| 22:57 | <Hixie> | anything beyond that and really what's the point, one should just use the real underlying elements |
| 22:57 | <Hixie> | like <select> or <input> |
| 23:14 | <jamesr> | so this, then? http://webstuff.nfshost.com/examples/canvas_form.html |
| 23:15 | <jamesr> | i haven't made the thing really clickable so you have to edit the checked state via the keyboard |
| 23:15 | <mpilgrim> | why do you hate mouse users?!? |
| 23:15 | <jamesr> | paaaah hit testing |
| 23:17 | <mpilgrim> | be sure to also emulate clicking on the label as a proxy for clicking on the checkbox itself |
| 23:17 | <jamesr> | well that's the thing, there are a _lot_ of behaviors here |
| 23:17 | <mpilgrim> | and drawing a focus ring on tabbing |
| 23:17 | <jamesr> | like dragging in/out of the checkbox |
| 23:17 | <jamesr> | i do draw the focus ring on tabbing |
| 23:17 | <jamesr> | i made that work |
| 23:17 | <mpilgrim> | i forget what we're doing, exactly |
| 23:18 | <jamesr> | Hixie: so what i'm getting at is if i have a checkbox, shouldn't i just be using an <input type="checkbox"> instead? |
| 23:18 | <jamesr> | and if not what behaviors of a real checkbox are we trying to allow canvas authors to emulate and what behaviors are we just ignoring? |
| 23:20 | <jamesr> | i guess i don't understand why focus ring is so special |
| 23:29 | <Hixie> | jamesr: in general i agree with you |
| 23:31 | <jamesr> | ok, so given this sort of use case do you think there's a significant difference to hiding the <input type="checkbox"> within the <canvas> vs hiding it with CSS? |
| 23:31 | <jamesr> | i have it invisible via position:absolute; top:-50000px and make it focusable via tabindex and a click listener |
| 23:32 | <Hixie> | CSS is merely decorative, if you're changing the semantics of the page with CSS then you're doing it wrong |
| 23:32 | <Hixie> | so i don't really see how CSS is relevant here |
| 23:33 | <Hixie> | jamesr: note that there are several "canvas AX" things, and they have rather different purposes |
| 23:33 | <jamesr> | i'm not changing the semantics, i'm changing the presentation of that checkbox |
| 23:33 | <jamesr> | Hixie: i'm trying to understand how they fit together |
| 23:34 | <Hixie> | i think it'd be a bit confusing for there to be two checkboxes, one on the canvas and one next to the canvas |
| 23:34 | <Hixie> | and i doubt any authors would do that |
| 23:34 | <jamesr> | in the visual presentation, yes |
| 23:34 | <jamesr> | that's what i am controlling with css |
| 23:34 | <Hixie> | css is optional |
| 23:34 | <Hixie> | the page should still work if i just turn off all css |
| 23:34 | <jamesr> | as far as the document model in the OO sense having them be sibling or child/parent does not seem particularly relevant |
| 23:35 | <Hixie> | it's relevant in that in the sibling case, you're saying they're both there, whereas in the child case, you're saying one replaces the other |
| 23:35 | <karlcow> | I have to remember that. I need more brain cycles on it "[18:37] <jamesr> i'm not changing the semantics, i'm changing the presentation of that checkbox" |
| 23:36 | <jamesr> | well, i'm not sure the document has valid semantics in either case |
| 23:36 | <jamesr> | at least to what my mind |
| 23:36 | <Hixie> | "valid semantics"? |
| 23:36 | <karlcow> | aha another one. |
| 23:37 | <karlcow> | it's becoming meta :) |
| 23:37 | <karlcow> | EIOUkdj soiu34897KJIu fjf 34jhkhf ksljd <- invalid semantics? |
| 23:37 | <Hixie> | jamesr: one problem we're trying to solve is how to make pages accessible to users with limited visibility, who use screen readers to orient themselves, but still see the page |
| 23:37 | <Hixie> | jamesr: for that, you want just one checkbox |
| 23:38 | <Hixie> | jamesr: but you need a way to expose it and its state to the AX tools, while rendering it using canvas |
| 23:38 | <Hixie> | jamesr: so by putting it as a child, we're saying that the canvas is being used for the rendering, but the checkbox element (<input type=checkbox>) "represents" the checkbox for the purposes of the AX tool. |
| 23:39 | <Hixie> | jamesr: (and for the purposes of conveniently having somewhere to keep track of sub-canvas focus) |
| 23:39 | <Hixie> | jamesr: (for keyboard users) |
| 23:42 | <Hixie> | jamesr: if you're around tomorrow i can come over and try to see if i can explain it in person |
| 23:43 | <Hixie> | jamesr: as your input on this stuff would be very much welcome :-) |