| 07:40 | <estellevw> | There were five global attributes related to microdata including itemid, itemprop, itemref, itemscope and itemtype that i remember seeing, but don't see in the spec right now. Am I missing something? |
| 07:46 | <myakura> | estellevw: they got split off from the main HTML5 spec about a month (or two) ago. |
| 07:46 | <estellevw> | thanks |
| 07:47 | <estellevw> | is it likely to come back in? |
| 07:48 | <myakura> | I guess the WHATWG version of HTML5 still incorporates it. |
| 07:48 | <myakura> | for W3C version, see http://www.w3.org/TR/microdata/ . |
| 07:49 | <estellevw> | yeah, looking at it |
| 07:49 | <estellevw> | i think it needs some editing. The attributes are in the body but not in the table of contents |
| 07:51 | <estellevw> | http://www.w3.org/TR/microdata/#attr-itemref and the like have lost their original stature. |
| 07:52 | <estellevw> | it states The following attributes are added as global attributes to HTML elements: |
| 07:52 | <estellevw> | * itemid |
| 07:52 | <estellevw> | * itemprop |
| 07:52 | <estellevw> | * itemref |
| 07:52 | <estellevw> | * itemscope |
| 07:52 | <estellevw> | * itemtype |
| 07:52 | <estellevw> | oops, sorry |
| 07:52 | <estellevw> | but if i recall correctly, those aren't listed in teh global attributes anymore |
| 07:53 | <estellevw> | the global attributes being here: http://www.w3.org/TR/html5/dom.html#global-attributes |
| 07:56 | <myakura> | because they are two separete specs; Microdata is build on top of HTML5 so those item* attributes cannot be defined in HTML5. |
| 07:59 | <estellevw> | ok, makes sense as to why role, and the aria-* attributes aren't listed as global even though they are too |
| 07:59 | <estellevw> | thanks |
| 07:59 | <myakura> | yeah.. |
| 08:00 | <myakura> | just refer to the WHATWG version and you won't get confused :) |
| 08:00 | <myakura> | MikeSmith: aloha |
| 08:01 | <estellevw> | i can still get confused, but i'll have to blame myself ;) |
| 11:28 | <MikeSmith> | myakura: here now |
| 11:29 | <MikeSmith> | hsivonen: if/when you are around and have time to chat, please ping me |
| 11:29 | <MikeSmith> | in regard to http://dev.w3.org/html5/spec/text-level-semantics.html#guidance-for-conformance-checkers |
| 11:42 | <MikeSmith> | writing code for a conformance checker to check "The img element is part of the only paragraph directly in its section" or even "only non-whitespace content in the only paragraph directly in its section" is not easy |
| 11:45 | <annevk> | prolly also depends on how you implement things |
| 11:46 | <MikeSmith> | well, it's not practical at all to implement using a grammar-based schema, so we forget about that completely |
| 11:48 | <MikeSmith> | and it's quite complicated to implement in the Java code that validator.nu currently uses for things that can't be checked practically using grammar-based checking |
| 11:50 | <MikeSmith> | as far as I can see, it will require adding code that is very unlike existing code for any other checking that is being done by validator.nu |
| 11:58 | <othermaciej> | MikeSmith: I think that particular exception is not very well justified in the first place |
| 11:58 | <othermaciej> | MikeSmith: but yeah, to check an "only paragraph in its section" condition would require running the HTML5 outline algorithm I think |
| 11:59 | <MikeSmith> | It would be help to have the spec provide the intended rationale for that exception |
| 12:00 | <othermaciej> | MikeSmith: Hixie explained it a bit in the specific bug Laura filed about it |
| 12:00 | <MikeSmith> | ok |
| 12:00 | <othermaciej> | let me see if I can find it |
| 12:01 | <othermaciej> | MikeSmith: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9217 |
| 12:02 | <MikeSmith> | I see |
| 12:02 | <othermaciej> | MikeSmith: I would personally think it was fine to say "just use figure" |
| 12:02 | <MikeSmith> | well, I think we could all live without that particular exception |
| 12:02 | <MikeSmith> | yeah, what you said |
| 12:03 | <othermaciej> | because associating the relevant section header with the image is much more complicated |
| 12:03 | <othermaciej> | as much as you don't want to implement it in the validator, I *really* don't want to implement the outline algorithm solely for our accessibility code to handle this case |
| 12:04 | <MikeSmith> | yep |
| 12:06 | <othermaciej> | I'm adding a comment to the bug |
| 12:06 | <MikeSmith> | OK |
| 12:10 | <othermaciej> | done |
| 12:11 | <othermaciej> | I mentioned the validator issue but feel free to comment as well |
| 12:12 | <othermaciej> | the rate of incoming bugs is just ridiculous |
| 12:12 | <othermaciej> | can't believe we are up to 90 already, there were about 42 just a few days ago |
| 12:13 | <MikeSmith> | well, in some ways, incoming bugs is a sign of progress |
| 12:13 | <othermaciej> | it's a sign of people reviewing the spec |
| 12:13 | <MikeSmith> | e.g., with the media-accessibility bugs that Silvia raised |
| 12:13 | <othermaciej> | which is good |
| 12:13 | <MikeSmith> | true that |
| 12:14 | <othermaciej> | I don't feel bad about incoming bugs, as long as the rate of outgoing bugs is also high |
| 12:47 | <myakura> | MikeSmith: I talked with Shiraishi-san on Friday about what we're gonna talk in Fukuoka. |
| 12:48 | <MikeSmith> | OK |
| 12:50 | <myakura> | MikeSmith: and their plan is to: Takuya will do the keynote-like talk (.5hr), and You and I do about Web Standards in general (like what you did at DevFest) |
| 12:50 | <MikeSmith> | sounds good so far |
| 12:51 | <myakura> | MikeSmith: Oli for markup stuff, Shiraishi-san will talk about APIs, and Anne to do about "CSS latest status" |
| 12:51 | <myakura> | and I'm not sure you guys heard about that |
| 12:51 | <myakura> | and whether you guys are okay with that. |
| 12:52 | <boblet> | oh, good timing |
| 12:52 | <boblet> | hey all |
| 12:54 | <myakura> | boblet: heya. |
| 12:54 | <boblet> | myakura: by markup stuff do you mean sectioning elements etc? |
| 12:54 | <boblet> | or also CSS? |
| 12:55 | <myakura> | MikeSmith: btw we have an hour for each session but for yours and Anne's I need to interpret so you guys will have shorter time (40min?) |
| 12:56 | <MikeSmith> | myakura: that sounds fine |
| 12:56 | <myakura> | boblet: the table only shows "HTML5 Mark up" ... |
| 13:00 | <boblet> | myakura: will check it out. thanks for the info. Guess I better read Mike’s slides |
| 16:34 | <jgraham> | It seems like AT would want access to the document outline in any case |
| 16:36 | <jgraham> | And presumably webkit will have to implment it anyway once we get :section(n) |
| 16:37 | <annevk> | if we ever decide to do that |
| 16:37 | <jgraham> | Well sure |
| 16:37 | <jgraham> | If we don't decide to do that the whole outline algorithm is likely a waste of time |
| 17:32 | <micheil> | hmm.. would this be the place to ask a quick question about one of your spec proposals? |
| 17:32 | <jgraham> | Yes |
| 17:33 | <micheil> | okay, with the websocket protocol, would I be right in assuming that one server would be able to server multiple different sockets / data sets to clients based on the paths at which they connect? |
| 17:34 | <jgraham> | With the proviso I am not an expert on that spec, yes |
| 17:34 | <micheil> | okay |
| 17:34 | <jgraham> | The server can do whatever it wants based on anything the client sends including the path part |
| 17:35 | <jgraham> | (subject to it meeting the requirements for a successful connection of course) |
| 17:36 | <micheil> | yeah, I'm just trying to work out how to direct data about by using that, all the reference implementations I can find don't indicate anything on that |
| 17:38 | <jgraham> | Well when the server recieves the client handshake it parses out the path so you can arrange for it to be passed to the app |
| 17:38 | <jgraham> | Not sure what existing implementations do though |
| 17:39 | <micheil> | yeah, just trying to think if it's possible to send data to a specific connection or not |
| 17:39 | <micheil> | (ie, rather then just being a broadcast type service) |
| 17:40 | <micheil> | I suppose because the writes to the network stream would be done from within a connection, you'd handle it there maybe.. |
| 17:41 | <jgraham> | If I follow you, that sounds right |
| 17:42 | <jgraham> | From the point of view of the server each client is a seperate connection so you can read and write to each client independently |
| 17:43 | <micheil> | hopefully |
| 17:43 | <jgraham> | I don't really see how it could work otherwise |
| 17:44 | <micheil> | I suppose I should just work out the raw tcp send switching first, then add on the websocket protocol |
| 17:46 | <MikeSmith> | jgraham: conformance checkers should not require access to the document outline |
| 17:47 | <jgraham> | MikeSmith: I didn't mean to have any opinion on conformance checkers |
| 17:47 | <jgraham> | Just other types of UA |
| 17:47 | <MikeSmith> | I see |
| 17:47 | <MikeSmith> | I can see that AT having access to the document outline would be good |
| 17:48 | <MikeSmith> | but then there are many things that AT should be doing that they are not currently |
| 17:49 | <jgraham> | Right, but I disagree with othermaciej's assertion that implementing the outline algorithm in the accessibility code would soley be for this case |
| 17:53 | <MikeSmith> | yeah, it'd certainly seem it could end j useful for |
| 17:54 | <MikeSmith> | .. end up being useful for lth |
| 17:54 | <MikeSmith> | oops |
| 17:54 | <MikeSmith> | ...useful for other things |
| 17:54 | <MikeSmith> | (my fingers are cold) |
| 17:55 | <jgraham> | ah, I was imagining that you had insane keyboard macros that could expand a few characters into whole sentences |
| 17:55 | <jgraham> | and they had broken |
| 17:55 | <MikeSmith> | heh |
| 17:59 | <MikeSmith> | I just came back from sento, in 水風呂 water that's 17.1 degrees |
| 18:04 | jgraham | assumes that is the kanji for "fucking cold" |
| 18:05 | <micheil> | it'd have to be less then 17 degrees outside here |
| 18:06 | <jgraham> | Well sure it is less than 17 degrees C outside here too |
| 18:06 | <jgraham> | But I wouldn't go in water that temperature |
| 18:06 | <jgraham> | The thermal conduction is a killer |
| 18:07 | <micheil> | actually. 20ºC here is cold. |
| 18:08 | <AryehGregor> | It's barely above 20°C here now, and it's starting to be summer already. |
| 18:09 | <micheil> | jgraham: I think the key to my websocket problem is in the http parsers (I'm working with node.js btw) |
| 18:10 | <micheil> | it's not even winter yet and it's 7.6ºC outside. |
| 18:10 | <micheil> | then again, I'm usually getting 30-45º in summer. |
| 18:17 | <MikeSmith> | micheil: I think maybe websocket isn't meant to be used with existing http parsers |
| 18:17 | <micheil> | MikeSmith: it isn't. however, the key to building a robust node.js websocket server implementation lies in how http servers work |
| 18:18 | <MikeSmith> | I'm not familiar with node.js or what its main use cases are |
| 18:19 | <micheil> | async / evented javascript with network and file i/o |
| 18:19 | <micheil> | built on the same javascript engine that powers chrome / chromium |
| 18:38 | <jgraham> | micheil: Do you get raw socket access with node.js? |
| 18:38 | <jgraham> | If you do I would start from there rather than with the existing http parser |
| 18:38 | <micheil> | yeah, raw tcp / sockets |
| 18:39 | <micheil> | although, node's http parser is built on it's net sockets, so I can use that as reference |
| 18:45 | <jgraham> | micheil: You might be just as well working from the simple echo server example in the documentation |
| 18:46 | <micheil> | not realy |
| 18:46 | <micheil> | not everything is documented, so there are some different ways to do things under the hood |
| 18:46 | <jgraham> | Or you sould take the existin websocket-in-node.js implementation and check that it supports the new handshake |
| 18:46 | <jgraham> | *could |
| 18:46 | <micheil> | (I wish the current net implementation was around when I started working on node-smtp-client) |
| 18:47 | <micheil> | jgraham: nawh, that takes away half the fun :P |
| 18:47 | jgraham | should finish his websocket-server-in-python-diesel implementation |
| 18:48 | <micheil> | heh heh, what I'm wanting to get from this is pretty specific |
| 18:55 | <AryehGregor> | Hmm, so Google is funding efficient ARM decoding of Theora. I still have hope that they'll switch YouTube from H.264 someday. |
| 18:59 | <jgraham> | AryehGregor: Well I don't doubt they will. They question is will it be to theora and soon or to H.264.next and not-so-soon |
| 18:59 | <AryehGregor> | Heh. |
| 18:59 | <JonathanNeal> | updated ie print protector; added summary element, wrapped entire script in ie conditional (instead of individual fns), and compressed window/document variables (all based on remy sharp suggestions) |
| 19:10 | <micheil> | hmm.. due to the way the websocket protocol is, I'm not likely to need much of a really heavy parser for the handshake (initial GET request), am I? |
| 19:11 | <jgraham> | micheil: You need to parse out the headers to get the websocket-sec-key (or whatever they are called) values |
| 19:12 | <jgraham> | And you need the random bytes |
| 19:12 | <micheil> | yeah, but I want need the same level of parser as what a standard http server would |
| 19:12 | <jgraham> | and there are some requirements about when you must drop the connection |
| 19:12 | <micheil> | hmm.. random bytes.. |
| 19:12 | micheil | checks it |
| 19:12 | <jgraham> | But no, a full HTTP stack isn't necessary |
| 19:13 | <micheil> | hmm.. |
| 19:13 | <micheil> | random bytes as in the ^n:ds[4u from the spec? |
| 19:14 | <jgraham> | The 8 bytes after the end of the part that looks like HTTP headers |
| 19:14 | <micheil> | which, according to http spec should probably be: ...headers..\r\n\r\nDATA\r\n\r\n |
| 19:14 | <micheil> | I think |
| 19:15 | <jgraham> | The HTTP spec isn't really relevant |
| 19:15 | <jgraham> | From the point of view of the HTTP spec they are the first 8 bytes of the body or so, I think |
| 19:19 | <micheil> | yeah, although, I'm just working out what I'll need to do to parser it |
| 19:36 | <Hixie> | simplest answer to that is to follow the rules in the parser section that tell you how to write the parser :-) |
| 19:36 | <Hixie> | section 5.1 |
| 19:36 | <micheil> | Hixie: heh, I suppose you'd be the man to ask :P |
| 19:37 | <micheil> | Hixie: is there any sane way that you read those documents? |
| 19:40 | <Hixie> | how do you mean? |
| 19:47 | <micheil> | well, there seems to be a lot of extra formatting on the IEFT / RFC type documents, is there a cleaner way to view them? |
| 20:40 | <jgraham> | micheil: If you can use the complete.html spec on the WHATWG site. It is a bitch to load but once it is loaded it is rather good to read |
| 21:23 | <annevk> | http://adactio.com/journal/1654/ -- I still think we should drop <article> and get <content> |
| 21:24 | <annevk> | though maybe just dropping <article> for now and see what patterns emerge |
| 21:40 | <Hixie> | annevk: i don't understand why people are so confused by them... they're completely differnet |
| 21:40 | <Hixie> | one is for chapters and the other is for syndicatable content |
| 21:40 | <Hixie> | they're different use cases with almost no overlap |
| 21:42 | <Dashiva> | Hixie: The confusion seems to be with the descriptions, maybe it's just a matter of condensing it down to a better explanation |
| 21:47 | <Hixie> | the descriptions are completely different |
| 21:47 | <Hixie> | i think the problem is that the element names aren't intuitive based on the descriptions |
| 21:48 | <Hixie> | but that's not a big problem, people will learn the difference in due course |
| 21:49 | <Hixie> | it's like <dl>, <ul>, and <ol>. Given just those element names and then descriptions of what they're for, how would you guess which was which? |
| 21:50 | <annevk> | hmm, would've been good to test that out |
| 21:51 | <othermaciej> | <article> and <section> as names sound very distinct |
| 21:51 | <othermaciej> | maybe the problem is with the descriptions |
| 21:54 | <othermaciej> | "The section element represents a generic document or application section." --> ""The section element represents a generic section of a document or application" |
| 21:54 | <othermaciej> | I bet that by itself would reduce confusion |
| 21:54 | <othermaciej> | if you skim fast, the current text looks like "The ____ element represents a document" |
| 21:55 | <othermaciej> | "The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication." |
| 21:55 | <othermaciej> | and that one reads as "The ____ element represents a component" if you skim |
| 21:56 | <othermaciej> | could be something like "The article element represents a self-contained composition in a document, page, application, or site that is intended to be independently distributable or reusable, e.g. in syndication." |
| 21:56 | <othermaciej> | Hixie: ^ |
| 21:56 | <othermaciej> | (annevk also) |