| 00:55 | <benschwarz> | Philip`: So the regular editions of the spec all receive a body element from your spec splitter? |
| 00:55 | <benschwarz> | and a closing html tag? |
| 00:59 | <Philip`> | benschwarz: Hmm... No |
| 00:59 | <Philip`> | Looks like I run it with the --html5lib-serialiser option (but no others) |
| 00:59 | <Philip`> | and the html5lib serialiser seems to omit optional tags by default |
| 01:00 | <benschwarz> | Philip`: They're the options that MikeSmith setup for me too |
| 01:00 | <Philip`> | The <html> and <body> aren't optional in e.g. http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html because they have attributes |
| 01:00 | <Philip`> | but </body> and </html> are always optional |
| 01:01 | <Philip`> | (and <body> with no attributes is optional, which is probably the case in your version of the spec) |
| 01:01 | <benschwarz> | Philip`: https://github.com/benschwarz/developers.whatwg.org/blob/master/Makefile |
| 01:02 | <benschwarz> | yeah, I have no <body> |
| 01:02 | <benschwarz> | all of which makes styling and modying after harder than it should be |
| 01:03 | <Philip`> | Styling via CSS selectors? There's still a body element in the DOM so you can style it exactly as if there was an explicit <body> written there |
| 01:04 | <Philip`> | although actually it probably breaks in some browsers because the first element is <header> which isn't always recognised as an element that triggers the implicit body |
| 01:05 | <Philip`> | You could add omit_optional_tags=False into the html5lib.serializer.HTMLSerializer(...) line in spec-splitter.py to make all open/close tags explicit |
| 01:58 | <benschwarz> | Philip`: *some* browsers add a body of its own |
| 01:58 | <benschwarz> | but mobile safari, for example, does not. |
| 01:59 | <benschwarz> | its foolish to rely on the consistent nature of browsers from different vendors |
| 02:00 | <benschwarz> | Either way, I really want to get those tags in there because it makes my job easier :) |
| 02:01 | <benschwarz> | Philip`: any reasons we're not using utf-8 encoding? |
| 02:02 | <benschwarz> | Philip`: hmm. now everything is within the head: view-source:http://developers.whatwg.org/ |
| 02:02 | <benschwarz> | :/ |
| 02:06 | <benschwarz> | ah. even wierder, there are two heads |
| 02:49 | <MikeSmith> | benschwarz: what different behavior do you see in mobile safari? |
| 02:49 | <MikeSmith> | benschwarz: btw, you know about Live DOM Viewer? |
| 02:49 | <MikeSmith> | http://software.hixie.ch/utilities/js/live-dom-viewer/ |
| 02:50 | <MikeSmith> | you can use that page in any browser to see the actual DOM that the browser constructs for any given document or markup fragment |
| 02:53 | <MikeSmith> | about the encoding, the reason I was running the splitter with the encoding set to ascii was that I had problems with characters getting borked by anolis or some other part of the toolchain in my processing setup |
| 02:54 | <MikeSmith> | you should switch it to utf-8 and if you don't see any problems just keep it that way |
| 03:00 | <MikeSmith> | benschwarz: I think any difference you see in mobile safari or other browsers is due to what Philip` mentioned |
| 03:01 | <MikeSmith> | that is, their html parsers don't know about the header element |
| 03:02 | <MikeSmith> | they don't know that <header> implies a <body> start tag |
| 03:02 | <MikeSmith> | so another way to solve that is not use <header> |
| 03:02 | <MikeSmith> | but instead use <div class=header> or something |
| 03:07 | <MikeSmith> | or maybe consider using the --w3c option |
| 03:08 | <MikeSmith> | which will do that for you I think |
| 03:10 | <MikeSmith> | hmm |
| 03:10 | <MikeSmith> | or maybe not |
| 03:10 | <MikeSmith> | maybe you need to do it with anolis |
| 03:12 | <MikeSmith> | hmm |
| 03:13 | <MikeSmith> | but I find no header element in the source nor any part of anolis or the splitter that generates one |
| 03:13 | <MikeSmith> | so I guess that means you are putting it in with your code |
| 03:14 | <MikeSmith> | in which case, it's even easier for you to fix :) |
| 03:34 | <eboyjr> | Will <div href="foo.html> be supported? I heard it was and I like the idea |
| 03:35 | <eboyjr> | with a quote after foo.html of course |
| 04:06 | <llrcombs> | ^^ seconded |
| 04:07 | <llrcombs> | it'd make <a> around <div> unneccesary |
| 04:07 | <llrcombs> | how about <anyBlockOrInlineElement href="anyUrl">? |
| 04:09 | <llrcombs> | I've always thought that most block and inline elements should be more or less the same at base, with some elements having added UI (<select>, <input>, etc.), attributes (<form action="blah">), or styling (<a> has the blue color and underline; <div> has display: block;, <span> has display: inline;) |
| 04:10 | <bga_> | chrome10 still buggy with playing many sounds parralelly |
| 04:10 | <bga_> | :( |
| 04:12 | <bga_> | or laggy |
| 04:13 | <Hixie> | eboyjr, llrcombs: http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_href_on_any_element.21 |
| 04:14 | <llrcombs> | true enough |
| 04:36 | <benschwarz> | Hixie: hi :) |
| 04:36 | <benschwarz> | I missed MikeSmith, damn |
| 04:39 | <Hixie> | benschwarz: hey |
| 04:39 | <benschwarz> | Hixie: I'm trying to ensure that we have a body element in the spec after it is split… |
| 04:39 | <Hixie> | compat with legacy UAs? |
| 04:42 | <benschwarz> | Hixie: I was seeing some strangeness with styling the body under iOS |
| 04:42 | <benschwarz> | I think Philip` has sorted me out with options for html5lib though :) |
| 04:43 | <Hixie> | k |
| 04:43 | <Hixie> | we can also change <header> to <div> for now |
| 04:43 | <Hixie> | there's no rush to use the new elements |
| 04:44 | <Hixie> | for the spec i am basically targetting ua vendors so making it use the latest stuff is fine, since they're likely using cutting edge UAs |
| 05:08 | <eboyjr> | About the href attribute thing, it says, "It adds no new functionality that can’t already be achieved using the a element and a little script.". Well what if javascript is turned off? |
| 05:09 | <eboyjr> | Browser vendors report that implementing it would be extremely complex, but you can work around it with a simple script.. hrm |
| 05:11 | <Hixie> | there's a lot of things like that |
| 05:13 | <eboyjr> | Heh HTML5 should group <dt>s and <dd>s together in <di>s!.. I just use <div>s hehe shhh |
| 05:25 | <benschwarz> | Hixie: I'm happy to use newer elements |
| 05:25 | <Hixie> | k |
| 05:27 | <benschwarz> | Hixie: unless we're having trouble styling them (which we're not, currently) |
| 15:07 | <AryehGregor> | Hixie, you never told me what the beforeundo/beforeredo events are supposed to me. I didn't find any info on them in a quick search. |
| 19:05 | <AryehGregor> | How best to write "If the length of input is congruent to 1 mod 4"? I've currently got "If the length of input minus one is divisible by 4". |
| 19:05 | <AryehGregor> | I'm thinking a lot of authors won't be so comfortable with modular arithmetic. |
| 19:08 | <Philip`> | "Let /length/ be the length of the input. If /length/ % 4 == 1 ..." |
| 19:08 | <Philip`> | then assume readers understand JS |
| 19:10 | <Ms2ger> | If <var>length</var>−1 is divisible by 4 |
| 19:10 | <Philip`> | Use MathML |
| 19:11 | <gsnedders> | Ms2ger: Any number is divisible by four. |
| 19:11 | <AryehGregor> | Is there some specific place for DOM Range tests? |
| 19:12 | <Ms2ger> | Put them up somewhere and tell me :) |
| 19:19 | <AryehGregor> | Now I'm confused by this: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624 |
| 19:19 | <AryehGregor> | Where are these attributes actually defined right now? |
| 19:21 | <AryehGregor> | Aha, now I see. |
| 19:21 | <AryehGregor> | Or not. |
| 19:24 | <AryehGregor> | Okay, I think I've got it now. |
| 19:25 | <Ms2ger> | http://html5.org/specs/dom-range.html |
| 19:30 | <AryehGregor> | Thanks. |
| 19:43 | <Hixie> | AryehGregor: yeah, i did some searches and came up empty. Not sure where I came up with those. |
| 19:43 | <AryehGregor> | Okay. |
| 19:55 | <abarth|socket> | othermaciej: you around? |
| 19:55 | <othermaciej> | abarth|socket: sorta |
| 19:55 | <othermaciej> | what's up? |
| 19:55 | <abarth> | i'm going to write up a draft of the websockets spec |
| 19:56 | <othermaciej> | interesting |
| 19:56 | <abarth> | can you give a quick brain dump of what you think the best design point is w.r.t. the state of the working group? |
| 19:56 | <abarth> | straw point pointed to upgrade+masking |
| 19:56 | <abarth> | your experiments point to AES-CTR |
| 19:57 | <abarth> | some folks seem concerned about export control |
| 19:57 | <abarth> | but that doesn't seem like a real issue |
| 19:57 | <othermaciej> | I am not sure of the details of how to do AES-CTR but still have a per-frame nonce |
| 19:57 | <othermaciej> | I don't think export control is a real issue |
| 19:57 | <othermaciej> | it's possible I am wrong |
| 19:57 | <abarth> | oh, that's easy, you just choose a nonce |
| 19:57 | <abarth> | and use that as the counter value |
| 19:57 | <abarth> | like choosing a new IV |
| 19:58 | <othermaciej> | let me break it down another way, and list what I think are the open questions where no consensus has been declared: |
| 19:58 | <abarth> | ok |
| 19:58 | <othermaciej> | - should masking cover the whole frame, or only the payload, or only payload plus extension data? |
| 19:58 | <othermaciej> | - should masking be built-in and default, or expressed as a mandatory extension? |
| 19:59 | <othermaciej> | - should the mask incorporate some fixed entropy from the client and server in addition to the per-frame values? |
| 19:59 | <othermaciej> | - should masking be a simple XOR, or should HMAC be used to generate a mask, or should we use AES-CTR? |
| 20:00 | <othermaciej> | - should a fake CONNECT be sent after the initial GET+Upgrade (and presumably after receiving the upgrade response)? |
| 20:00 | <benschwarz> | Hixie: !ping |
| 20:01 | <othermaciej> | I'm not sure if anyone at this point is arguing to still use HELLO frames combined with masking |
| 20:01 | <abarth> | ok, my thoughts are: |
| 20:01 | <abarth> | 1) whole frame |
| 20:01 | <abarth> | 2) build-in and default |
| 20:01 | <abarth> | 3) use client and server entropy in the key, but not each per-frame nonce |
| 20:02 | <abarth> | 4) AES-CRT |
| 20:02 | <abarth> | 5) No fake CONNECT |
| 20:02 | <Hixie> | benschwarz: yo |
| 20:02 | <benschwarz> | any way that we can mark the implementation seperatly? |
| 20:03 | <Hixie> | how do you mean? |
| 20:03 | <othermaciej> | abarth: sounds like a sensible set of choices to me |
| 20:04 | <abarth> | my basic thoughts are that we've delayed long enough |
| 20:04 | <abarth> | and we should pick something reasonable and declare victory |
| 20:04 | <Hixie> | we'd delayed long enough 6 months ago |
| 20:04 | <Hixie> | good luck |
| 20:04 | <abarth> | Hixie: thanks |
| 20:08 | <benschwarz> | Hixie: mark it was implementation for real, then I can hide it? |
| 20:08 | <Hixie> | benschwarz: sorry i really have no idea what you're referring to |
| 20:08 | <Hixie> | benschwarz: can you give me a bit more context? |
| 20:08 | <benschwarz> | Hixie: sorry, our email |
| 20:09 | <Hixie> | oh the reflection things? |
| 20:09 | <benschwarz> | yeah |
| 20:09 | <Hixie> | the problem is that there's nothing other than the implementation stuff for the reflected attributes |
| 20:09 | <Hixie> | at the moment |
| 20:09 | <Hixie> | there's the line in the idl, then some line in the prose that says "the foo idl attribute must reflect the foo content attribute", and that's it |
| 20:10 | <Hixie> | (where "reflect" is defined in an earlier section in lots of detail) |
| 20:13 | <benschwarz> | Hixie: which would also be okay to not show on the developers edition |
| 20:13 | <benschwarz> | okay. lets leave what I've got and see if there are any objections |
| 20:13 | <benschwarz> | that make sense, anyway |
| 20:13 | <benschwarz> | ie/ someone can fight me for it |
| 20:14 | <benschwarz> | Hixie: I just wanted to know that I was going to be removing something else important |
| 20:16 | <Hixie> | yeah |
| 20:16 | <Hixie> | originally i was gonna mention all the reflected attributes somewhere |
| 20:17 | <Hixie> | but i gave up since the idl was visible |
| 20:17 | <Hixie> | but maybe i should go through at some point and mention them again |
| 20:19 | <othermaciej> | abarth: I look forward to your draft |
| 20:19 | <abarth> | othermaciej: fette sent me the XML for this draft, i'm editing it now. hopefully i'll have it posted later today |
| 20:19 | <benschwarz> | Hixie: maybe just start doing it with the new ones and sweep through over time |
| 20:20 | <benschwarz> | it can't hurt to have more meta in the spec |
| 20:20 | <benschwarz> | Hixie: did you see the *red*? |
| 20:20 | <Hixie> | when i do it i'll just do them all at once |
| 20:21 | <Hixie> | i noticed you'd changed the styles if that's what you mean :-) |
| 20:21 | <benschwarz> | Hixie: if you have an ipad or iphone around, give a look on those too |
| 20:21 | <Hixie> | btw once thing you might want to hide in the dev copy is a[href^="#refs"] |
| 20:21 | <Hixie> | don't have any handy |
| 20:22 | <benschwarz> | I did see those, they're link references that are shown in the references section? |
| 20:22 | <Hixie> | yeah |
| 20:22 | <Hixie> | they're needed in the normative copy for precision, but they make the spec a bit ugly to read |
| 20:22 | <benschwarz> | I was going to come up with some way to pull through the link and style it somehow |
| 20:22 | <Hixie> | ah that works too |
| 20:22 | <benschwarz> | but it all got hard quickly… |
| 20:22 | <Hixie> | maybe a link in the margin or something |
| 20:22 | <benschwarz> | I'll work something out |
| 20:23 | <Hixie> | most of them frankly devs just won't care |
| 20:23 | <benschwarz> | yeah exactly, pull the reference into an "aside" |
| 20:23 | <Hixie> | i'd just drop the entire references section if i were you |
| 20:24 | <benschwarz> | Hixie: anyway, I started reading through on my ipad last night |
| 20:24 | <benschwarz> | going from zero—hero with this when I'm done won't be hard |
| 20:25 | <benschwarz> | I want to explore adding rel="next" and rel="previous" to the table of contents and using some script to navigate on touch-based devices |
| 20:27 | <benschwarz> | actually, they're in the head already |
| 20:36 | <Hixie> | benschwarz: looking good. |
| 20:36 | <benschwarz> | Hixie: ok. Its 740am. I gotta get ready for the first day of work and head out. Email is good if you want to get at me |
| 20:36 | <Hixie> | k |
| 20:36 | <Hixie> | later dude |
| 20:36 | <Hixie> | thanks again for all the hard work! |
| 20:37 | <benschwarz> | Enjoying it ;) |
| 20:39 | <benschwarz> | Later, all. |
| 21:15 | <Huvet> | what's the right channel to ask about html5lib? |
| 21:16 | <Hixie> | here's a good place, when the right people are around |
| 21:16 | <Ms2ger> | Huvet, just ask |
| 21:19 | <Huvet> | thanks, was unsure if this was the right place: I'm trying to search the tree produced by html5lib with css selectors. This is the code I'm trying, and I'm just getting an empty array back: http://pastebin.com/CbpL6bF0 - any idea what I did wrong or where I should ask? I'm thinking this is a html5lib+lxml incompatibility |
| 21:19 | <gsnedders> | Huvet: You need to specify the namespace for the XPath queyr. |
| 21:19 | <gsnedders> | *query |
| 21:20 | <Huvet> | oh, yeah, things are namespaced with lxml, right |
| 21:20 | <Huvet> | I keep forgetting that, because "regular" css is not |
| 21:22 | <Huvet> | I see a warning about settings namespaceHTMLElements=False, but it seems to work: http://code.google.com/p/html5lib/issues/detail?id=138 - Bad idea? |
| 21:22 | <Huvet> | "Add a warning about us being broken when set to False." |
| 21:27 | <Huvet> | thanks btw gsnedders! :) |
| 21:28 | <Hixie> | css is namespaced too, it's just that the default namespace is "*" which matches everything |
| 21:28 | <Hixie> | ("foo" in css is the same as "*|foo", which matches "foo" in all namespaces) |
| 21:28 | <Hixie> | (unless you explicitly declare a namespace) |
| 21:29 | <Huvet> | ah, so it's really a bug in lxml's parsing of css to xpath, they should add the namespace too? |
| 21:29 | <Hixie> | dunno, now we're out of my area of expertise :-) |
| 21:31 | <Huvet> | ok, but then I take it I won't break things by disabling namespaces when parsing |
| 22:08 | <miketaylr> | list |
| 22:42 | <Hixie> | abarth: make sure the key header is sent before the url header, so you can't sometimes smuggle a key header in the url |
| 22:42 | <Hixie> | actually, just make sure the key comes first |
| 22:42 | <Hixie> | since the other headers also have author-controlled values |
| 22:44 | <Hixie> | abarth: also, "Any status code other than 101 must be treated as a failure" should be s/must/will/ since that's an informative section |
| 22:44 | <Hixie> | abarth: actually there's a few more musts in that section |
| 22:46 | <Hixie> | christ the framing got complicated |
| 22:47 | Hixie | gets lost during the framing section and gives up |
| 23:01 | <abarth> | ok |
| 23:02 | <abarth> | yeah, i don't understand the framing at all |
| 23:10 | <othermaciej> | it seems like the framing changes took the total number of fields from 3 to 10 |
| 23:11 | <othermaciej> | though at least 5 of those are reserved for future extensions |
| 23:11 | <othermaciej> | abarth: btw I'm not trying to troll you about OPTIONS, I just want Willy to put up or shut up if he has a real problem with it |
| 23:11 | <othermaciej> | it seems like a good idea to me |
| 23:34 | <Hixie> | if neither abarth nor i can understand the protocol framing at first glance, it might be worth simplifying... |
| 23:36 | <Hixie> | but i'll let someone else take up that battle |
| 23:41 | <abarth> | othermaciej: i didn't mean to change anything in the framing |
| 23:41 | <abarth> | othermaciej: it just used the text that ian sent me |
| 23:41 | <othermaciej> | abarth: I don't mean your change |
| 23:41 | <othermaciej> | I mean relative to the old (Hixie era) framing |