| 00:05 | <Steve^> | Text within a <footer> must also be wrapped in a <p>? |
| 00:20 | <aho> | Steve^, nop. but it might be handy to have some extra hook for styling purposes |
| 00:21 | <Steve^> | Aha, Text is flow content |
| 00:22 | <Steve^> | Just making sure I can reproduce your answer from the docs :) |
| 00:23 | <aho> | well, it's just like a div... just with some meaning tacked on :> |
| 00:24 | <Steve^> | True, though I wasn't sure in that content either |
| 00:24 | <Steve^> | context |
| 00:25 | <aho> | "when in doubt, validate" ;) |
| 00:25 | <aho> | makes everything easier |
| 01:13 | <Steve^> | For example on this section: http://dev.w3.org/html5/spec/Overview.html#e-mail-state it does not appear to list the actual value for the email state, "email" |
| 01:14 | <Steve^> | It is listed in the table above, but it'd be nice to not have to cross-reference |
| 01:40 | <Hixie> | "actual value"? |
| 02:07 | <Steve^> | The value to go into the type attribute |
| 09:38 | <micheil> | Hixie: in what ways is the websocket protocol spec moving forward from the (what seemed like) a break down in communication between WHATWG and IETF |
| 09:38 | <micheil> | ? |
| 09:46 | <annevk5> | micheil, it's a tad more complicated than that |
| 09:47 | <micheil> | okay, explain then |
| 09:47 | <annevk5> | heh, could have expected that |
| 09:47 | <micheil> | because I'm totally lost at the moment as to what's going on. |
| 09:47 | <annevk5> | we're still communicating |
| 09:48 | <micheil> | okay, it sounded like there was a break down of communication. |
| 09:49 | <annevk5> | I'm not quite sure where it is heading though, but everyone is still there and nobody has been ousted |
| 09:49 | <micheil> | okay |
| 09:50 | <annevk5> | it's mostly that people have somewhat varied views on how extensibility is to be addressed |
| 09:50 | <micheil> | well, are we still going ahead with the draft76 style packet format, or moving towards the VI one? |
| 09:50 | <micheil> | erm, Framing Take IV |
| 09:51 | <annevk5> | ranging from WG in control to wide-open (and also way more complicated) |
| 09:51 | <micheil> | hmm.. |
| 09:51 | <annevk5> | Hixie changed the framing |
| 09:51 | <micheil> | well, from an implementors perspective, using the Framing Take IV is a hell of a lot simpler. |
| 09:51 | <micheil> | did he? |
| 09:51 | <annevk5> | it now uses 64-bit |
| 09:52 | <micheil> | okay, you've lost me there; let me read up on the spec. |
| 09:53 | <annevk5> | http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#protocol-overview |
| 09:53 | <annevk5> | frames are now |
| 09:53 | <annevk5> | frame-type frame-length data |
| 09:53 | <micheil> | one moment, safari's busy crashing trying to load the compelte one :P |
| 09:53 | <annevk5> | with frame-length being a length encoded as 8 octets |
| 09:53 | <annevk5> | (the above is multipage) |
| 09:54 | <micheil> | okay, cool |
| 09:55 | <micheil> | so what, is it still using \x00 and \xFF as the start/end delimeters? |
| 09:56 | <micheil> | or are we using just a message is frame-length long |
| 09:56 | <annevk5> | a message with a type that is frame-length long |
| 09:57 | <micheil> | okay, example? |
| 09:57 | <annevk5> | they're in the spec? |
| 09:58 | <annevk5> | one octet for type (only text and closing supported currently); eight octets for lengths as unsigned 64-bit int; data blob |
| 09:59 | <micheil> | so, example packet may be: <0xFF><11><hello world> |
| 09:59 | <micheil> | <11> being a big endian 64 bit int |
| 10:00 | <micheil> | <hello world> being UTF8 encoded binary data? |
| 10:00 | <annevk5> | yes |
| 10:01 | <micheil> | okay |
| 10:01 | <micheil> | and, if the content was say, binary, it might be something like <0xFE><11><binary data> |
| 10:02 | <micheil> | where <binary data> would be 11 bytes of binary data |
| 10:03 | <micheil> | (if binary data were to be supported) |
| 10:03 | <micheil> | would it make more sense to have one frame-type reserved for metadata, where an example might be: |
| 10:04 | <micheil> | <0xF0><13><Encoding=UTF8> |
| 10:04 | <micheil> | which would tell the server that the client expects data to be encoded with UTF8 encoding |
| 10:05 | <annevk5> | that requires API changes |
| 10:05 | <annevk5> | on top of which we do not want to support more than one encoding for text |
| 10:05 | <micheil> | (this would be sent onconnect by the client, but could also be sent by calling ws.setEncoding(enc) ) |
| 10:05 | <micheil> | where enc maybe a DOMString of either: "binary" or "utf8" |
| 10:06 | <annevk5> | seems simpler to just have a different frame type |
| 10:06 | <micheil> | okay |
| 10:06 | <micheil> | that sounds fair enough then |
| 10:06 | <micheil> | but then, how do I change between binary and utf8 data? |
| 10:06 | <micheil> | (without requiring massive changes) |
| 10:07 | <micheil> | I'm thinking that when the server receives that Encoding=UTF8, it will then encode all out-going messages as UTF8 data |
| 10:07 | <micheil> | if it receives Encoding=Binary, it will then encode all out-going messages as raw binary data |
| 10:09 | <micheil> | because otherwise the server cannot send binary data |
| 10:09 | <micheil> | unless you make everything always binary data, and only have the clients decode to utf8 or something |
| 10:09 | <micheil> | but that's not a good direction to go |
| 10:12 | <annevk5> | once binary support is there the server can do whatever it wants |
| 10:12 | <annevk5> | and the javascript library will just handle binary and strings |
| 10:12 | <annevk5> | and in the transition period you can tell the server with a simple text message that your client supports binary |
| 10:12 | <micheil> | yeah, but if the data coming in on the "message" DOMEvent is UTF8 encoded, then you'd have to do odd stuff |
| 10:12 | <annevk5> | from the application layer |
| 10:13 | <annevk5> | a different frame type would be exposed differently in the API |
| 10:14 | <annevk5> | (maybe not for all future frame types; but binary and strings get their own primitive; but since JS doesn't have one for binary; we're waiting) |
| 10:14 | <micheil> | okay, I think it'd make sense to emit just one event "message" |
| 10:16 | <micheil> | and then to change the encoding of those message events, you call a client side API of setEncoding("...") |
| 10:16 | <annevk5> | no |
| 10:17 | <micheil> | okay |
| 10:17 | <annevk5> | just like with XMLHttpRequest send() will just be overloaded |
| 10:18 | <annevk5> | and the data attribute of the message event will be a ByteArray (or whatever it ends up being) rather than a DOMString |
| 10:18 | <annevk5> | (it's of type any after all) |
| 10:20 | <micheil> | okay, so inside ws.send's function, it'd be something like: if(typeof data === "string") { send as string } else if(typeof data === "bytearray") { encode to binary } |
| 10:21 | <micheil> | would that also mean that the onmessage api would need to do that same, or would it get given the content type? |
| 10:21 | <micheil> | eg, server sends a binary message, then a utf8 message, then another binary message |
| 10:22 | <micheil> | would the events still be: message, message, message, message |
| 10:22 | <micheil> | and would you still get (data) as the arguments to the function call? |
| 10:22 | <annevk5> | it would be just message |
| 10:22 | <micheil> | or would you get: (data, binary) |
| 10:22 | <annevk5> | but data would be of varied type |
| 10:23 | <micheil> | okay |
| 10:24 | <micheil> | so I'd need to manually check for typeof data |
| 10:24 | <annevk5> | you'll always need to do some kind of check; but yes |
| 10:25 | <micheil> | okay |
| 10:25 | <micheil> | and there's no more usage of that end delimiter format, right? |
| 10:25 | <annevk5> | having said all this, nobody has patched their browser implementation just yet |
| 10:25 | <micheil> | there's just one packet format, no high or low byte messages or what ever they were? |
| 10:26 | <annevk5> | micheil, right (that's not coming back) |
| 10:26 | <micheil> | (I'm just wanting to get up to speed) |
| 10:26 | <micheil> | I kinda got lost wading through the 200 odd emails in 1 or so days last week |
| 10:26 | <annevk5> | well, the binary/text stuff has remained the same; it's just the packaging that's different now |
| 10:27 | <annevk5> | from an API point of view nothing really changed |
| 10:27 | <annevk5> | yeah, it's kind of crazy |
| 10:27 | <micheil> | yeah |
| 10:27 | <micheil> | as long as both text and binary share the same actually packaging around them when sent on the wire, I'm cool with that. |
| 13:00 | <gsnedders> | Wikipedia is distracting. |
| 13:12 | <annevk5> | and writing a complete test suite is hard |
| 13:12 | <annevk5> | even "just" for XMLHttpRequest |
| 16:24 | AryehGregor | discovers apt-get install pastebinit |
| 16:29 | gsnedders | discovers he is incapable of writing for any period of time now |
| 16:33 | <Philip`> | gsnedders: I'd blame Twitter |
| 16:35 | <Philip`> | (Also, IRC) |
| 16:35 | <micheil> | the main part is getting into the right mental frame to be able to write. |
| 16:40 | <gsnedders> | micheil: A length delimited or sential delimited frame? |
| 16:41 | <micheil> | >_> |
| 16:41 | <micheil> | preferably a length delimited frame |
| 16:53 | <Workshiva> | I would prefer sentinel delimited, with the sentinel being "I have nothing more that needs writing" |
| 16:53 | <annevk5> | would be nice if dev.w3.org had a favicon |
| 16:54 | <micheil> | Workshiva: hmm, that could work |
| 18:10 | hdhoang | encounters a page for which html5 parser is more useful than chromium's \o/ ( http://www.ishmael.org/Education/Writings/ ) |
| 18:49 | <gsnedders> | "Note: There will be at least one such element, by definition." — I don't get how there will be. |
| 18:51 | <Ms2ger`> | <p class="note">There will be at least one such element, by definition.<!-- (If there wasn't, then this algorithm wouldn't have been invoked by Web IDL.) --></p> |
| 18:51 | <gsnedders> | Ah |
| 18:51 | gsnedders | tries to work out why |
| 18:53 | <gsnedders> | Oh, the "corresponding name property", I think… |
| 19:06 | <gsnedders> | Philip`: You had a bug on SpiderMonkey about Math.sin varying between x86 and x86-64, no? |
| 19:16 | <Philip`> | gsnedders: https://bugzilla.mozilla.org/show_bug.cgi?id=531915 ? |
| 19:16 | <gsnedders> | Philip`: Yeah, thanks |
| 19:24 | <gsnedders> | Philip`: Also, if you want more things to test in your canvas test suite, you could take a look at http://codingforums.com/showthread.php?t=198624 |
| 20:10 | <AryehGregor> | No one much seems to have commented on the srcdoc issue. |
| 20:10 | <AryehGregor> | http://www.w3.org/2002/09/wbs/40318/issue-100-objection-poll/ |
| 20:37 | AryehGregor | has his doubts about whether srcdoc is actually very useful, to be honest |
| 22:09 | <Hixie> | seriously tempted to ask if i can use http://alexkessinger.net/story/html5-brief-one-paragraph as the abstract for the spec |
| 22:35 | <Steve^> | I notice that the intention is for the UA to replace the content of <time> with a locale-specific form. I think it'd be helpful to have a set format describing how the UA would do this, or else it is difficult to use the value in the right context |
| 22:36 | <Steve^> | For example it may be important to the content to stress that a date was on a saturday. So I could do Saturday <time datetime="2010-08-07">8th August</time>. But for all I know the UA could convert this to Saturday Sat 8th Aug 2010 |
| 22:41 | AryehGregor | is a little skeptical of the idea of locale-specific rendering here. |
| 22:41 | <Workshiva> | Steve^: Where does it say that? |
| 22:42 | <AryehGregor> | Hmm, it seems not to? Good. |
| 22:42 | <AryehGregor> | Sounds like a bad idea. |
| 22:42 | <Steve^> | In the time element text |
| 22:42 | <Steve^> | Here is another way that could be marked up. In this example, legacy user agents would say "today", while newer user agents would render the time in a locale-specific manner based on the value of the attribute. |
| 22:42 | <AryehGregor> | Oh, wait. |
| 22:42 | <Steve^> | ^ quote |
| 22:42 | <AryehGregor> | That's non-normative. |
| 22:43 | <AryehGregor> | What it actually says in normative text is "If the datetime attribute is present, the user agent should convey the attribute's value to the user when rendering the element." |
| 22:43 | AryehGregor | is unsure whether that's useful. |
| 22:43 | <Steve^> | What does non-normative mean? |
| 22:44 | <AryehGregor> | Means "not really part of the standard, just meant to help you understand the actual requirements, ignore it if it contradicts normative text". |
| 22:44 | <Steve^> | Oh |
| 22:44 | <Steve^> | The text I refer to isn't even inside the non-normative "box" |
| 22:44 | <Workshiva> | But there seems to be something in the bindings section |
| 22:45 | <AryehGregor> | It's in <div class="example">, thus non-normative. |
| 22:45 | <Workshiva> | When the time binding applies to a time element, the element is expected to render as if it contained text conveying the date (if known), time (if known), and time-zone offset (if known) represented by the element, in the fashion most convenient for the user. |
| 22:45 | <Steve^> | I didn't read the code... |
| 22:46 | <Steve^> | I'm a little confused now to your opinion on the matter |
| 22:46 | <Steve^> | Is the spec right or wrong? |
| 22:46 | <Workshiva> | Steve^: It looks like you're right |
| 22:46 | <Steve^> | I'm right that it's silly? |
| 22:47 | <Workshiva> | Maybe |
| 22:47 | <Steve^> | As an aside, this non-normative stuff sounds misleading and shouldn't be in the spec if it's not valid |
| 22:48 | <Workshiva> | Well, "a locale-specific way" gives the UA a license to do pretty much anything it wants |
| 22:49 | <Steve^> | which is impossible for content authors to predict |
| 22:49 | <AryehGregor> | File a bug. |
| 22:49 | <Workshiva> | I think it's one of those problems that won't actually occur |
| 22:49 | <AryehGregor> | Why not? |
| 22:49 | <Steve^> | It seems that there are two seperate use cases here: One for text that should be easily cross-referenced to a calendar and the second for showing dates in a locale-specific manner |
| 22:49 | <Workshiva> | That UAs will magically all decide on formats that don't include the day of week |
| 22:50 | <Steve^> | Sure |
| 22:50 | <AryehGregor> | But why do we actually want it to be locale-specific? |
| 22:50 | <AryehGregor> | That would just be weird. |
| 22:50 | <AryehGregor> | Like a Chinese person seeing dates in Chinese on an otherwise English page? |
| 22:50 | <Steve^> | I think these two use cases conflict... with the former I probably want the value of "today" or "Saturday" to persist, with the true date hidden until asked for |
| 22:51 | <Workshiva> | AryehGregor: More like "Let the user configure the browser to show a sensible date format instead of that American rubbish" |
| 22:51 | <Steve^> | AryehGregor, 10/02/2010 vs 02/10/2010 for 10th Feb |
| 22:51 | <AryehGregor> | And if you're trying to guess whether 6/7/2010 refers to June 7 or July 6, you now have to not only take into account whether the site you're on is mainly American or British, but also try to guess whether it used <time>, and if so, what your browser thinks the right order is for you? |
| 22:51 | <AryehGregor> | Seems like a recipe for confusion. |
| 22:52 | <AryehGregor> | In the markup, but it could still be ambiguous in the display. |
| 22:52 | <Workshiva> | If the user wants it to be |
| 22:52 | <Steve^> | hmm |
| 22:52 | <Steve^> | I think the likely case is that the display will always be informal |
| 22:53 | <Steve^> | But I somewhat agree |
| 22:53 | <Steve^> | The first use case is the important one |
| 22:53 | <AryehGregor> | Which? |
| 22:53 | <Steve^> | Calendar integration |
| 22:53 | <AryehGregor> | Yes. |
| 22:53 | <AryehGregor> | Also <time pubdate> is nice for search engines. |
| 22:53 | <Steve^> | yes |
| 22:54 | <AryehGregor> | I don't think <time> should be displaying stuff differently from what its contents indicate. |
| 22:54 | <AryehGregor> | Authors can script that if they like, it doesn't need to be on the browser level. |
| 22:54 | <AryehGregor> | Alternatively, users could configure their browser to do it via an extension or something. |
| 22:54 | <AryehGregor> | It shouldn't be mandated by the spec. |
| 22:54 | <Steve^> | It would result as <time pubdate datetime="2010-05-25" /> 25th May |
| 22:54 | <Steve^> | Seperate, to avoid the browser messing with your styles |
| 22:55 | <Steve^> | Thus, you can dynamically show "Today", "Yesterday", "25th May" |
| 22:55 | <Steve^> | The browser can't decide that for you, but twitter styles feeds would insist on it |
| 22:57 | <Steve^> | AryehGregor, I should file a bug in bugzilla? |
| 22:57 | <AryehGregor> | Yes, you can use the form at the bottom of the WHATWG version of the spec. |
| 22:57 | <AryehGregor> | Post the URL of the bug so I can voice support. |
| 22:57 | <Workshiva> | If you want to track the bug, it's better to file manually |
| 22:57 | <Workshiva> | That way you get properly registered as reporter |
| 22:57 | <Steve^> | What is the different between the two versions? |
| 22:58 | <Workshiva> | The spec form is anonymous |
| 22:58 | <Steve^> | Ok, http://www.w3.org/Bugs/Public/enter_bug.cgi ? |
| 22:58 | <Steve^> | (Is that the right one for the right spec?) |
| 22:59 | <AryehGregor> | Yeah. |
| 23:14 | <Steve^> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10318 |
| 23:54 | <cardona507> | hola boyz |