| 00:02 | <jgraham> | I wonder if users really do distinguish "safe" and "unsafe" UI elements. I seriously doubt it but the HTTP people seem to believe it religiously. It would be nice to see actual evidence |
| 00:03 | <Dashiva> | jgraham: Maybe someone should tell them about CSS |
| 00:03 | <jgraham> | Dashiva: It might break their hearts |
| 00:04 | <BenMillard> | jgraham, I typically act on what I expect to happen rather than how it was presented or how it works. |
| 00:04 | <BenMillard> | so if I click something which says "Confirm My Order" then I expect it to do that, whether it's an <a href> using GET or an <input type="submit"> using POST |
| 00:05 | <jgraham> | BenMillard: Agreed. I tend to assume that links marked "Delete" will be non-idempotent... |
| 00:06 | <Philip`> | My bank uses buttons that don't look like real buttons, though they are quite buttony - they're just black text on a white background, with a single-pixel black border around them |
| 00:06 | <jgraham> | Which it turns out that my university webmail uses... |
| 00:07 | <jgraham> | As does squirrelmail |
| 00:09 | <jgraham> | flickr uses identical buttons for things that are links as for things that are actions |
| 00:09 | <Philip`> | It's a bit peculiar how that webmail system inserts an incrementing ID value into every request via the link URLs |
| 00:09 | jgraham | concludes that any user who believed HTTP rather than using their common sense would quickly come to grief |
| 00:11 | <takkaria> | Philip`: what, squirrelmail? |
| 00:12 | <Philip`> | takkaria: No, jgraham's university webmail |
| 00:12 | <jgraham> | Philip`: You mean the last number in the link? |
| 00:13 | <Philip`> | (I think the university wrote the whole thing themselves) |
| 00:13 | <Philip`> | (Also they wrote Exim themselves) |
| 00:13 | <jgraham> | s/last/first/ |
| 00:14 | <Philip`> | jgraham: If by "number" you mean "string of letters", then yes |
| 00:14 | <jgraham> | "Number base 26" |
| 00:15 | <Dashiva> | base 26, rot 10? |
| 00:15 | <Philip`> | (The AAAD in /session/abc123//AAAD@list@12345@13456) |
| 00:15 | <jgraham> | Yeah |
| 00:15 | <Philip`> | (where all links on the page go to URLs with "AAAE" in them) |
| 00:16 | <Philip`> | It seems a quite server-stateful model |
| 00:17 | <Dashiva> | Gotta love sites that keep state in URLs |
| 00:17 | <Dashiva> | I tried shopping on such a site |
| 00:18 | <Dashiva> | If you open a new tab to look at two items, you create two separate shopping baskets |
| 00:18 | <Philip`> | Has anyone at the IETF noticed yet that not all their RFCs are US-ASCII? |
| 00:19 | <Philip`> | (e.g. http://tools.ietf.org/rfc/rfc303.txt seems to be ISO-8859-1) |
| 00:21 | <Dashiva> | Philip`: That's just a bug |
| 00:21 | <Dashiva> | As long as it's a bug, you don't have to care about it |
| 00:34 | <Philip`> | I hate how Google changes link hrefs to track me when I click on search results, because if I open a link in a tab then close it then copy the link's URL, it copies the mangled tracking version :-( |
| 00:58 | <takkaria> | IMAP requires an excessive amount of state-keeping |
| 01:00 | <roc> | I hate copying and pasting links from a search results page and embarrassing myself |
| 01:00 | <roc> | that's why I support <a ping> |
| 01:02 | <Philip`> | Is there a solution to the problem that you'd want to use ping for users with browsers that support it, and old-fashioned tracking solutions for everyone else? |
| 01:04 | <Dashiva> | You could "solve" that by doing UA sniffing, but the real problem would also include people with ping support, but disabled |
| 01:05 | <Philip`> | No it wouldn't, since you'd want to Not Be Evil and would send ping to users whose have explicitly disabled ping, so all that matters is whether their browser supports the feature |
| 01:05 | <Philip`> | s/whose/who/ |
| 01:06 | <Dashiva> | You could also do both with a local @ping the first time the user visits, and then store "supports @ping" in a cookie if you get that |
| 01:06 | <roc> | so few people would disable it, they don't matter |
| 01:07 | <Philip`> | Dashiva: That sounds like a horrid hack |
| 01:08 | <Hixie> | the search engine results page links were the source of the first request |
| 01:11 | <Philip`> | roc: IE8 goes to some lengths to prevent third-party sites tracking you when it's in its private browsing mode, so I suppose Microsoft thinks people sometimes care about being tracked, and so those people would care about disabling ping too |
| 01:11 | <Philip`> | (This is separate from the don't-let-my-parents-know-what-I'm-looking-at aspects of the private browsing mode) |
| 01:12 | <Hixie> | disabling ping="" in the porn browsing mode seems quite reasonable |
| 01:13 | <roc> | yeah, and again, this is where ping enhances privacy |
| 01:13 | <Dashiva> | Philip`: Well, you could simplify it a lot by having opt-in ping support instead, but then most users wouldn't benefit :) |
| 01:15 | <Philip`> | So it does matter that sites can detect users who have browsers that support ping but who have chosen to disable ping because they don't want to be tracked, so the sites can intentionally not track them (instead of using their legacy fallback tracking mechanisms which they use for IE6/etc users) |
| 01:36 | Hixie | wonders how best to respond to this feedback: |
| 01:36 | <Hixie> | > I also believe that issuing an unsafe HTTP request in the context of |
| 01:36 | <Hixie> | > page navigation is in conflict with the web architecture. |
| 01:51 | <Lachy> | Hixie, there are some issues with the way iframe is defined that does make it slightly harder for authors who are uninterested in processing requirements to understand... |
| 01:51 | <Lachy> | e.g. the definition of the name attribute.: "The name attribute, if present, must be a valid browsing context name." |
| 01:51 | <Hixie> | yeah iframe certainly isn't ideal |
| 01:51 | <Hixie> | i expect to find a bunch of things that need phrasing better when i go through and annotate everything for the views work |
| 01:51 | <Lachy> | That should say something about what the name attribute means from an authoring perspective and what it should be used for. |
| 01:52 | <Lachy> | but I intend to document everything like that in the authoring guide anyway |
| 01:52 | <Lachy> | and since I am writing that guide, I find these requests for splitting the spec to be quite redundant |
| 01:53 | <Lachy> | especially because it was essentially the same arguements last year that led to the creation of the authoring guide |
| 02:03 | <Lachy> | one thing that is really bugging me about all these requests to split the spec up into numerous specs for each feature is that it makes significantly harder to figure out which spec to look in for a particular feature; instead of just going to one spec and searching within it for the feature |
| 02:04 | <Lachy> | I used to have that problem all the time with the DOM specs, although with experience I've learned where to look for most things |
| 02:05 | <Hixie> | fwiw, the whatwg version of the spec will be one document for all of html5 regardless of what contortions i have to go through to generate the w3c documents |
| 02:05 | <Lachy> | to some extent, I still have that problem with the multipage version of this spec, which is why I always use the single page version |
| 02:05 | <Hixie> | (with exception for the storage and websockets bits) |
| 02:05 | <Lachy> | yeah, that's fair enough. I don't have a problem with shifting those to their own spec in the webapps group |
| 02:07 | <Lachy> | but I must say as an author, having the DOM APIs along side the element definitions makes it significantly easier and is why, in many cases, despite the claims to the contrary on the list |
| 02:07 | <Lachy> | s/and is why// |
| 02:09 | <Hixie> | yeah i personally think it's awesome |
| 02:10 | <Lachy> | for the authoring guide, I'm going to include the DOM APIs, but I'm going to include a view feature that shows information based on what the user wants and their skill level |
| 02:11 | <Lachy> | much like what you've said you'll make for the spec |
| 02:11 | <Lachy> | (we could probably even use the same script once it's written) |
| 02:13 | <Hixie> | yeah |
| 02:23 | <Lachy> | I don't understand what problem including PING in the request body solves. It seems like an unnecessary extra 4 bytes to send for no reason and the need to define a new text/ping MIME type |
| 02:24 | <Hixie> | reply on the thread |
| 02:34 | <Lachy> | this reply only says that you included it, but doesn't really give any justification for it other then perhaps Julian's spec purity concerns http://lists.w3.org/Archives/Public/public-html/2008Nov/0473.html |
| 02:35 | <Hixie> | the reasoning for adding it was to allow hosts to recognise them based on the content-type |
| 02:35 | <Lachy> | but I guess fighting the uselessness of it would be more work than accepting it and implementing it |
| 02:35 | <Lachy> | ok |
| 02:35 | <Hixie> | if we get a PING method it'll become moot and i'll remove the body |
| 06:00 | <Hixie> | so, of all the talk about keygen, there isn't a single person who has said how you would use this ke |
| 06:00 | <Hixie> | key |
| 07:51 | <hsivonen> | MikeSmith++ for moratorium |
| 07:52 | <MikeSmith> | hsivonen: sorry I didn't get around to it sooner |
| 07:54 | <MikeSmith> | We had a three-day weekend here, and I was offline for most it, trying to actually enjoy it. |
| 07:54 | <MikeSmith> | we seem to have an unfortunate pattern of some of the most contentious discussions happening on weekends |
| 07:55 | <MikeSmith> | anyway, I'll try to a much better job of staying on top of things (as far as keeping the discussions productive) |
| 07:59 | <MikeSmith> | hsivonen: speaking of productive discussions, the discussion with Karl Berry about the GNU error format seems like a bit of a clash of cultures |
| 08:00 | <hsivonen> | oops. I have an unreplied email in my inbox |
| 08:01 | <MikeSmith> | given the decision-making regime at GNU, and the constraints that Karl has expressed, I'm wonder how useful what we end up with will be |
| 08:03 | <MikeSmith> | hsivonen: anyway, it seems like you've volunteered to try to do their work for them. I hope you can manage to put together something that can make it past the RMS veto. |
| 08:15 | MikeSmith | reads hsivonen's reply |
| 08:16 | <MikeSmith> | hsivonen: it might be useful for further discussions to move back to whatever GNU mailing list it was where we started this |
| 08:17 | hsivonen | really doesn't like the concept that encoding is a property of the computer |
| 08:17 | <hsivonen> | MikeSmith: which list was it? |
| 08:18 | MikeSmith | is looking now |
| 08:18 | <hsivonen> | s/computer/system installation/ |
| 08:18 | <MikeSmith> | hsivonen: bug-standards⊙go |
| 08:18 | <MikeSmith> | I'll send a reply to Karl suggesting that |
| 08:19 | <hsivonen> | MikeSmith: ok |
| 08:42 | <hsivonen> | Hixie: do you intend to write spec language for an iframeless conformance class of consumers? |
| 08:42 | <hsivonen> | Hixie: if not, do we really care about conformance requirements for iframe text content? |
| 08:43 | <Hixie> | no, and it's possible that we can get away with saying it has to be blank, i don't know how many people want to allow iframe to fallback |
| 08:44 | <hsivonen> | considering that Netscape 4 is dead, are there iframeless browsers except Opera when configured to be one? |
| 08:45 | <hsivonen> | I wonder how many people use Opera with iframes disabled now that Web apps use iframes for non-advertising purposes |
| 08:50 | <Hixie> | it certainly would be convenient for us to be able to say it must be empty. :-) |
| 08:51 | <hsivonen> | Hixie: have you checked if it really is empty virtually all the time on real sites? |
| 08:51 | <Hixie> | no |
| 08:58 | <hsivonen> | HTML5 support in the W3C Validator seems to be of a lot of interest on twitter |
| 09:16 | <MikeSmith> | hsivonen: the availability of it at the W3C site definitely seems to have created some buzz |
| 09:17 | <MikeSmith> | I don't know if people just didn't know about validator.nu before, or what |
| 09:36 | <hsivonen> | MikeSmith: I think support in the W3C Validator is perceived to give more legitimacy and a feeling of almost-readyness to HTML5 itself |
| 09:40 | <MikeSmith> | hmm, the "give more legitimacy" part is a clear win for us, but not sure the "feeling of almost-readyness to HTML5 itself" part is. I would hope it doesn't lead people to get disappointed and start commenting that any element that the validator tells them is HTML5-valid should be supported in browsers already. |
| 10:18 | <gsnedders> | r2433 ftw. |
| 10:19 | gsnedders | waits for people to complain that there really was a 0th year |
| 10:23 | <Hish> | hi. can anybody give me a hint what tag would best describe a tabulator as used in MS word etc.? currently I use a <span class="tab"> for this... |
| 10:34 | <Hixie> | Hish: i believe you want a css feature |
| 10:35 | <Hish> | Hixie: I thought about this as well but at the end of the day, a tabulator is very close to a table structure. So, I'm really not sure if a tabulator really is only presentation... |
| 11:02 | <Hish> | Hixie: one more question: is there a tag which lets me define a data range, i.e. row/col 2/2 to 6/6 of a table so that I can use this range within the output tag? |
| 11:02 | <Hixie> | no |
| 11:03 | <Hish> | thx |
| 11:04 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cinput%20placeholder%3D'text%0Atext%0Atext'%3E%0A |
| 11:04 | <hsivonen> | interesting in WebKit |
| 11:05 | <Hixie> | hah |
| 11:25 | <Hixie> | so... <input type=file multiple> would result in different actual fields in the field data set per file |
| 11:26 | <Hixie> | but with <input type=email multiple> |
| 11:26 | <Hixie> | what do we do with input.value? |
| 11:32 | <Hixie> | maybe we should introduce input.values |
| 11:33 | <Hixie> | i'd make it comma-separated but that would suck because addr-spec can contain commas |
| 11:39 | <Hixie> | hmm... |
| 11:39 | <Hixie> | maybe make .value contain the value if multiple="" is absent, and be empty otherwise |
| 11:40 | <Hixie> | and have .values be null except for this case, and in this case have it return some sort of mutable DOMStringList |
| 11:40 | <Hixie> | not that i really want to have to invent a whole new API just for this |
| 11:41 | <Hixie> | i could just disallow the quoted-string part of addr too |
| 11:43 | <Hixie> | aw man and domain-literal has crazy ass syntax too |
| 11:43 | <hsivonen> | Hixie: what's your expected fallback behavior? |
| 11:43 | <Hixie> | who the hell invented this |
| 11:43 | <Hixie> | hsivonen: using .value would have nice fallback behavior |
| 11:44 | <Hixie> | but if i do that i really have to redefine addr-spec to be radically simpler |
| 11:44 | hsivonen | notes that Mail.app allows the user to type a comma after an email address |
| 11:44 | hsivonen | wonders how that works if the addresses can contain commas |
| 11:45 | <Philip`> | Gmail splits addresses on commas too |
| 11:45 | <Hixie> | they can only contain commas in quoted bits |
| 11:45 | <hsivonen> | Hixie: can the addresses be whitespace-separated? |
| 11:45 | <hsivonen> | good XML and SGML vocabularies separate tokens with whitespace |
| 11:46 | <Hixie> | "foo,bar"@[\,].com appears to be a valid e-mail address |
| 11:46 | <Hixie> | as does " "@[\ ] |
| 11:46 | <hsivonen> | that's crazy |
| 11:46 | <hsivonen> | Does email delivery with addresses like that work? |
| 11:46 | <Hixie> | i doubt it |
| 11:47 | <Hixie> | i'm just gonna redefine addr-spec to be what users expect |
| 11:47 | <Hixie> | dot-atom "@" dot-atom |
| 11:47 | hsivonen | expects more controversy with HTML5 redefining things from the IETF realm |
| 11:48 | <Philip`> | Why does anything have to be redefined, rather than just defining new terms? |
| 11:49 | <hsivonen> | Philip`: you mean defining a new term like "Web email address"? |
| 11:49 | <Hixie> | well i didn't redefine addr-spec |
| 11:50 | <Hixie> | i just defined "Valid email address" |
| 11:50 | <hsivonen> | Hixie: are you coordinating this with mailto URIs? |
| 11:50 | <Hixie> | no. |
| 11:51 | <Hixie> | mailto: is defined in rfc2368 and allows the whole gamut of batshit crazy stuff like comments and quoted strings and backslash-escaped characters and everything. |
| 11:51 | <Hixie> | we're already (as of wf2) narrower than that |
| 11:51 | <Hixie> | i'm just making it even narrower. |
| 11:52 | <Philip`> | hsivonen: I mean defining a new term like "sensible-addr-spec", rather than redefining addr-spec, since it sounded like that was possible what people were talking about |
| 11:52 | <hsivonen> | Philip`: ok |
| 11:56 | <Lachy> | Hixie, how will a <input type=email name=name multiple> element be submitted? Will it be like this: ?name=a⊙x&name=b⊙x |
| 11:56 | <hsivonen> | Lachy: that would be backwards-incompatible |
| 11:57 | <Lachy> | so it would need to be ?name=<some delimted list of emails> |
| 12:09 | <Lachy> | Hixie, AUDITNAV is a bad name to use. If PING isn't acceptable, now about something like NOTIFY? |
| 12:10 | <Philip`> | TRACK! |
| 12:10 | <hsivonen> | BIKE |
| 12:10 | <Philip`> | As a bonus, people couldn't fake it with XHR |
| 12:11 | <Hixie> | Lachy: tell julian, not me |
| 12:11 | <Hixie> | i'll use whatever he gets approved |
| 12:13 | Philip` | agrees that PING is a bad name, because it's got pretty much nothing to do with what everyone else in the computer networking world means by 'ping' (i.e. a reachability/RTT-measurement tool) |
| 12:16 | Lachy | isn't motivated enough to start another naming debate on the list. |
| 12:16 | <Hixie> | i agree that for the http name PING is suboptimal |
| 12:17 | <Hixie> | i don't care if it's AUDITNAV or something else |
| 12:17 | <Hixie> | NOTIFY seems a bit vague for what we're defining, but it could be defined more vaguely too |
| 12:17 | <Lachy> | AUDIT would be better |
| 12:17 | <Hixie> | i just don't really care |
| 12:17 | <Hixie> | i have enough troubles with html, http can take care of itself :-) |
| 12:19 | <hsivonen> | http://en.wikipedia.org/w/index.php?title=Document_Type_Declaration&diff=253488659&oldid=prev |
| 12:19 | <hsivonen> | typical wikipedia |
| 12:22 | <broquaint> | Anyone know if there will be a JS interface to form data handling in the upcoming specs? Specifically I'm thinking of something like: var fData = someForm.toPostData(); window.location = '/path?' + fData; |
| 12:23 | <broquaint> | Because currently there's no native way of doing it and any naive implementation will vary from browser to browser AFAICT. |
| 12:29 | <Hixie> | can't you just set the form's action to "/" and post the form normally? |
| 12:31 | <broquaint> | Sure, but if you've got existing data (be it form based or otherwise) there's no programmatic way to get a multipart/form-data representation. |
| 12:32 | <broquaint> | I'm not sure if this is relevant to #whatwg's goals but I figure I can be pointed in the appropriate direction if not :) |
| 12:32 | <Hixie> | why would you want that representation? |
| 12:33 | <broquaint> | For AJAX mainly. |
| 12:33 | <Hixie> | it's definitely something that would be in our goals if you can convince us there's a good reason for it :-) |
| 12:33 | <broquaint> | Ooh, interesting :) |
| 12:34 | <Lachy> | it's interesting how wikipedia is incorrectly using the abbreviation "DTD" to mean Document Type Declaration |
| 12:34 | Lachy | will fix it |
| 12:35 | <Lachy> | hmm, well, perhaps their not. It's just ambiguous since their using headings like "HTML 4.01 DTDs" |
| 12:36 | <Hixie> | nn |
| 12:36 | <broquaint> | So, for example, if you wanted to do an XHR with the POST method using multipart/form-data there's no standard way of stitching the data together such that it is indistinguishable from the browser's equivalent. |
| 12:37 | <broquaint> | Perhaps I should put a mailing list message together ... |
| 12:49 | <hsivonen> | does wikipedia have something like cvs blame? |
| 12:51 | hsivonen | finds this piece of encyclopedic writing: "There is currently no indication as to whether HTML 5 will support RDFa, or be limited just to microformats." |
| 13:20 | <Dashiva> | Hey, new last week |
| 13:21 | <Philip`> | I think Mr Last Week doesn't quite understand the concept of "week", given the variation in posting frequency |
| 13:24 | <Philip`> | contenteditable would be great if it was just slightly less buggy in Firefox |
| 13:36 | <hsivonen> | contenteditable is also underdefined |
| 13:37 | <hsivonen> | yesterday, I learned that Gecko's editor has a dependency on the HTML containment rules of the HTML parser |
| 13:38 | <hsivonen> | whoa. since when has contenteditable accepted the empty string |
| 13:39 | <Philip`> | Since at least IE6 |
| 13:39 | <Philip`> | which is nice because you can do <span contenteditable>...</span> |
| 13:40 | Philip` | is just using contenteditable for plain text, so he doesn't care how it handles HTML markup |
| 13:40 | <Philip`> | (though I wouldn't mind if there were some way I could force it to be plain markup and prevent users inserting fancier things) |
| 13:42 | <Philip`> | Oh, hmm, paste is really badly broken in my contenteditable spans in FF3 :-( |
| 13:43 | <yecril71> | The suggestion to provide an explicit baseline for time stamps is recursive. |
| 13:44 | <yecril71> | The baseline would have to be denoted somehow as well, |
| 13:44 | <yecril71> | so it would possibly depend on its own baseline, |
| 13:44 | <yecril71> | and so on. |
| 13:58 | <Philip`> | Gmail wins again! "Would you like to... Add to calendar - scheduled for Weekly on Tuesday, Thu..." - yes, thank you for letting my add the hypothetical garbage collection on the paved form login cowpath into my calendar |
| 13:59 | <Philip`> | Someone needs to teach Gmail to understand metaphors |
| 14:00 | Dashiva | blinks |
| 14:01 | <Lachy> | Philip`, what? |
| 14:01 | <Lachy> | nothing you just said makes sense to me |
| 14:01 | <Dashiva> | Is that referring to a message on public-html? |
| 14:01 | <Dashiva> | And it picked up some sentence as being a potential calendar item? |
| 14:02 | <Philip`> | Lachy: Gmail applies some heuristics to email messages so it can offer useful services, like adding meetings mentioned in the email into your calendar |
| 14:02 | <Philip`> | or like tracking DHL packages that were mentioned in the email |
| 14:03 | <Philip`> | and in every single case I've seen, it's got it totally wrong and misinterpreted the emails (in this case one of Hixie's recent messages to the WHATWG list) |
| 14:03 | <Lachy> | yeah, I understand that. But "paved form login cowpath" doesn't make sense at all |
| 14:03 | <Philip`> | See "Solving the login/logout problem in HTML" |
| 14:04 | <Philip`> | around the 11th paragraph |
| 14:04 | <Philip`> | "The form login cowpath is so commonly frequented that not only has someone already gone and paved it but it has also been tree-lined, has garbage collection scheduled for Tuesdays and Thursdays, and will be electing a representative at the next general election." |
| 14:05 | <Dashiva> | What happens if there are two (or more) forms with the name given in the www-authenticate header? |
| 14:05 | <Philip`> | Dashiva: Or none? |
| 14:06 | <Dashiva> | Philip`: none is simple, means you don't get to login :) |
| 14:08 | <Philip`> | Dashiva: "The form parameter, if present, indicates that the first form element in the entity body whose name is the specified string, in tree order, if any, is the login form." sounds pretty clear on that |
| 14:09 | <Dashiva> | Huh, missed that |
| 14:10 | <Dashiva> | So I guess allowing several different auths on the same login page wouldn't work |
| 14:12 | Philip` | isn't quite sure why you'd want to tell the UA where the login form is |
| 14:13 | <Philip`> | because the UA can't be a bot that logs in automatically, since it doesn't know the names of the username and password fields in the identified login form |
| 14:13 | <Philip`> | and the UA can't highlight the form to the user because highlights are ugly and disturb the page design, so authors would want control of that themselves instead |
| 14:15 | <Dashiva> | Finding the password field isn't that hard :) |
| 14:16 | <Philip`> | Oh, that's a good point |
| 14:21 | <Lachy> | gsnedders, yt? |
| 14:34 | <yecril71> | Is there a chance someone fixes the negative margin on DL in the specification? |
| 14:34 | <yecril71> | It makes the element section headers invisible. |
| 14:35 | Philip` | sees that http://planet.intertwingly.net/ now includes Mr Last Week |
| 14:43 | <hsivonen> | now I can get a dose of workplace stalking from my favorite mobile destination |
| 14:46 | jgraham | notes that the time of th big bang is constrained to much better than 1 billion years, assuming scientists aren't hopelessly wrong about everthing |
| 14:47 | <yecril71> | Why are SCRIPT elements not allowed within TABLE elements? |
| 14:47 | <yecril71> | It seems if the table rows are written by JavaScript, so must be the TABLE tags. |
| 14:47 | <Philip`> | jgraham: It only requires scientists to be hopelessly wrong about one thing, not about everything |
| 14:47 | <Philip`> | jgraham: and I trust scientists to be hopelessly wrong about several things |
| 14:48 | <Philip`> | (though I don't know which several things those are, and I trust the scientists to sort it out in the end) |
| 14:48 | <jgraham> | Philip`: Well it would require them to be wrong in specific ways about specific things. |
| 14:50 | <Philip`> | I suppose the scientists could always cheat by just redefining the concept of time so that they are correct |
| 14:50 | <jgraham> | (fwiw the uoted uncertianty is about 1% i.e. about 100 million years rather than 10% i.e. 1 billion years) |
| 14:50 | <jgraham> | s/uo/quo/ |
| 14:52 | <jgraham> | (However the use case of <time>5 seconds after the big bang</time> is clearly silly |
| 14:52 | <jgraham> | ) |
| 15:28 | <Philip`> | Hmm, it seems Julian took seriously my idea to use the TRACK method |
| 15:28 | <Philip`> | Maybe it is actually a sensible idea, though that wasn't my intention at all |
| 15:30 | <yecril71> | Why isn�t form structure fully reflected in the DOM? |
| 15:30 | <yecril71> | A FORM knows its elements, a FIELDSET does not. |
| 15:30 | <yecril71> | An INPUT control does not know its LABEL. |
| 15:31 | <yecril71> | Or a FIELDSET it belongs to. |
| 15:31 | Philip` | isn't sure what yecril71 means |
| 15:31 | <yecril71> | It would be nice to have these properties (read-only). |
| 15:31 | <Philip`> | Oh, like having an HTMLInputElement.label property or something? |
| 15:32 | yecril71 | means introducing DOM properties |
| 15:32 | <yecril71> | Right. |
| 15:32 | <Dashiva> | A control can have many labels |
| 15:32 | <yecril71> | .label can return a collection |
| 15:34 | <yecril71> | or just the first label, in document order |
| 15:34 | <Philip`> | Obvious question: what are the use cases that would be solved by adding these properties? |
| 15:34 | <Dashiva> | And you might want to check the spec |
| 15:34 | <Dashiva> | Some of them are already in |
| 15:34 | yecril71 | thinks having multiple lables is bad design |
| 15:35 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-lfe-labels |
| 15:38 | <yecril71> | Thanks. I see a fieldset has elements and an input has labels. |
| 15:39 | <yecril71> | How about adding INPUT.fieldset? |
| 15:39 | <Philip`> | What for? |
| 15:40 | <yecril71> | To differentiate response to an event by the fieldset the control is in. |
| 15:41 | <yecril71> | Since we have the other two, .fieldset would just complete the picture. |
| 15:41 | <Dashiva> | Completing the picture isn't a use case |
| 15:42 | <yecril71> | If course, one can go up the DOM to find the nearest fieldset. |
| 15:42 | <Philip`> | 'Completeness' sounds like it's arguing for theoretical purity, which usually isn't considered a worthwhile goal |
| 15:42 | <yecril71> | Completing the picture was an additional comment. |
| 15:43 | <Philip`> | Is differentiating responses to events based on the fieldset a problem that occurs in practice, enough to justify the cost of adding the feature to HTML5? |
| 15:44 | <Philip`> | s/enough/often enough/ |
| 15:45 | <yecril71> | I do not know; I have just happened to find it useful so I decided to ask. |
| 15:46 | <yecril71> | I think .fieldset was left out because there exists an easy workaround, |
| 15:46 | <yecril71> | unlike the other cases. |
| 15:46 | <Philip`> | It seems like something that could be useful and isn't supported yet, but it's not clear whether it's worth supporting in the language rather than telling people to navigate the DOM themselves |
| 15:47 | <yecril71> | It is not clear to me either. |
| 15:49 | <Philip`> | Just use jQuery and then all this is trivial :-) |
| 15:49 | <Philip`> | $(input).parents('fieldset:first') or whatever |
| 15:52 | <yecril71> | Since OBJECT is submittable now, it needs to be associated with a FORM. |
| 15:53 | <yecril71> | The association is not historical any more. |
| 15:57 | <Dashiva> | Oh snap, I got told |
| 15:58 | <Dashiva> | But since Lachy works for Opera, the point is somewhat lessened :) |
| 15:59 | <yecril71> | And what is the use case for FIELDSET.name? |
| 15:59 | <Lachy> | Dashiva, what? |
| 15:59 | <Dashiva> | Last last week |
| 16:02 | <gsnedders> | "philip the WHAT WG teamster rebel" |
| 16:02 | <gsnedders> | Philip`'s stealing my title! |
| 16:03 | <Dashiva> | yecril71: Fieldsets appear in the form elements collection |
| 16:03 | <Lachy> | oh, wow. I love how Mr Last Week is defending me from MikeSmith in such a sarcastic way |
| 16:04 | <yecril71> | Right, thanks. |
| 16:04 | <gsnedders> | haha. |
| 16:04 | <gsnedders> | That is nice. |
| 16:05 | <Philip`> | gsnedders: Since when were you a rebel? |
| 16:05 | <gsnedders> | Philip`: I'm constantly going against Hixie's opinions, and getting killed for it |
| 16:05 | jgraham | wonders if gsnedders is confusing real life with a FPS |
| 16:06 | <jgraham> | Becuse in real life it is hard to constantly get killed |
| 16:06 | <gsnedders> | jgraham: FPS!? Third-person shooters is where it's at1 |
| 16:06 | <gsnedders> | *! |
| 16:06 | <Philip`> | Why does nobody write second-person shooters? |
| 16:06 | <jgraham> | gsnedders: Just put it this way, if you respawn in RL people ill get freaked out |
| 16:07 | <gsnedders> | I think those would be harder to control than third-person shooters, Philip` |
| 16:07 | <jgraham> | Or start some sort of major world religion I guess |
| 16:07 | <gsnedders> | jgraham: I do freak people out, though |
| 16:07 | <Dashiva> | Philip`: I've considered it |
| 16:07 | <Dashiva> | There is a second-person horror game on the playstation, I believe |
| 16:07 | <Lachy> | Philip`, probably because no-one has figured out how to market a game where the aim is to get yourself shot |
| 16:08 | <jgraham> | Lachy: That would be awesome |
| 16:08 | <Lachy> | yeah, but it would be too easy to just stand out in the open |
| 16:08 | <jgraham> | Maybe you could only control people indirectly like you had to annoy the neighbourghs enough that they eventually went postal |
| 16:09 | <Lachy> | maybe it would work if the other characters in the game were on your side and intentionally trying not to hit you, so you had to position yourself in such a way that you would get hit by friendly fire |
| 16:11 | <yecril71> | And why are fieldsets listed? |
| 16:11 | <yecril71> | They are not listed in HTML4, |
| 16:11 | <yecril71> | and they are not form controls, |
| 16:12 | <yecril71> | so the name HTMLFormControlsCollection is not really appropriate. |
| 16:13 | <yecril71> | I understand it is practical to ask for all fieldsets, |
| 16:13 | <yecril71> | but it is already covered by getElementsByTagName. |
| 16:43 | <Philip`> | If I'm using lxml, how do I iterate over all h1, h2, and h3 elements? |
| 16:43 | <Philip`> | node.iter('h1') works, but node.iter('h1|h2') doesn't and I can't find any syntax that does |
| 16:43 | <jgraham> | you could use xpath |
| 16:44 | <jgraham> | (alhough it may not be the most efficient way and returns a lsit not an iterator) |
| 16:44 | <BenMillard> | "I very much hope we can (through W3C and MWI) drive user awareness of the mobile Web as a platform and start to create a mindset among developers and users that it's "OK" to have a different user experience between different devices / platforms - that this can be consistent with there being One Web." -- http://www.w3.org/QA/2008/11/_as_part_of_a.html |
| 16:44 | <BenMillard> | doesn't sound like One Web to me... |
| 16:45 | <Dashiva> | Different user experience as in different styling and device-specific widgets, or as in different pages entirely? |
| 16:46 | <BenMillard> | "'Full Web' to me is a code word for 'web pages designed exclusively for PCs.'" ouch, guess he never used a good mobile browser... |
| 16:47 | <jgraham> | Philip`: Or I guess just do [x for x in node.iter() if x.tag in ('h1','h2', 'h3')] |
| 16:47 | <jgraham> | (but that is kind of obvious) |
| 16:49 | <BenMillard> | this makes sense: "The idea is to allow the proxies to do their work on pages that have not taken mobile users into account, while stepping out of the way when a content provider has developer a service that adapts for mobile anyway." |
| 16:49 | <BenMillard> | such as webpages using HTML 4.01 Strict, with a handheld stylesheet, I assume (lol) |
| 16:49 | <BenMillard> | "I will say that the growth of flat-rate data plans is a positive trend in the industry right now and I hope that trend continues." me too! |
| 16:51 | <BenMillard> | "I sincerely hope the HTML Working Group considers our work in CDF before they re-invent the wheel." I hadn't heard of CDF before now... |
| 16:54 | <smedero> | BenMillard: CDF has been brought up many times in the SVG in HTML discussions, search public-html. |
| 16:56 | <smedero> | (though, not in a particularly compelling way...) |
| 16:57 | <BenMillard> | smedero, CDF comes from here? http://www.w3.org/2004/CDF/ |
| 16:57 | <smedero> | yep |
| 16:58 | <gsnedders> | What's a good human readable and computer parsable biblio format? |
| 16:59 | <jgraham> | gsnedders: Bibliography? |
| 16:59 | <gsnedders> | jgraham: yeah |
| 16:59 | <jgraham> | bibtex is pretty standard for LaTeX applications |
| 17:00 | <jgraham> | Dunno if it meets your needs |
| 17:00 | <gsnedders> | I just want something for Anolis that isn't Refer |
| 17:00 | <gsnedders> | And it needs to be easy to parse in Python :P |
| 17:00 | <BenMillard> | smedero, this seems quite a stretch from the Mobile Web's Default Delivery Context: http://www.w3.org/TR/2007/CR-WICD-20070718/#child-objects |
| 17:01 | BenMillard | concludes CDF is FAIL. |
| 17:02 | <jgraham> | http://pybliographer.org/ |
| 17:02 | <gsnedders> | jgraham: Can you import a GPL module into a MIT licensed project? |
| 17:03 | <jgraham> | Incidentially I _really_ have no idea if bibtex is sutiable for what you want |
| 17:03 | <gsnedders> | BibTeX is suitable |
| 17:03 | <jgraham> | gsnedders: IANAL |
| 17:03 | <gsnedders> | My IANAL opinion would be it is questionable |
| 17:06 | <jgraham> | http://groups.google.com/group/comp.lang.python/browse_thread/thread/cd8646451aacfcc9 |
| 17:06 | <Lachy> | gsnedders, you can, but it means that any distribution that includes the GPL'd code is effectively licenced under the GPL |
| 17:08 | <gsnedders> | There appears to be other bibtex scripts in Python |
| 17:08 | <gsnedders> | like, MIT licensed ones |
| 17:11 | <jgraham> | gsnedders: That sounds altogether like a better idea |
| 17:13 | <jgraham> | gsnedders: Where are the MIT licensed ones? |
| 17:13 | <rubys> | Lachy's correct |
| 17:14 | <gsnedders> | jgraham: http://code.google.com/p/bibstuff/ looks best |
| 17:14 | <rubys> | http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean |
| 17:17 | <gsnedders> | woah. |
| 17:18 | <gsnedders> | The W3C doesn't have any exportable format of TRs, as far as I can see! |
| 17:18 | <jgraham> | exportable? |
| 17:18 | <gsnedders> | like, more than just http://www.w3.org/TR/ |
| 17:18 | <gsnedders> | like, that I can use to build a bibtex file of all W3C TRs |
| 17:21 | <jgraham> | http://www.w3.org/2002/01/tr-automation/tr.rdf |
| 17:21 | <Philip`> | gsnedders: http://www.w3.org/2002/01/tr-automation/tr.rdf ? |
| 17:21 | <Philip`> | Oops, I lose |
| 17:21 | <gsnedders> | Where did you find any link to that!? |
| 17:22 | <Philip`> | http://google.com |
| 17:22 | <Philip`> | and http://www.w3.org/2002/01/tr-automation/ |
| 17:22 | <Philip`> | (I searched for "w3c tr list") |
| 17:22 | <jgraham> | In the <head> (I assumed that the W3C couldn't have a list without having accompnying RDF) |
| 17:23 | <gsnedders> | Philip`: I failed to google for the right thing |
| 17:23 | <gsnedders> | jgraham: So did I. Which was why I was amazed to not find it in two seconds. |
| 17:25 | <jgraham> | "Benefits of using Semantic Web technologies |
| 17:25 | <jgraham> | @@@" |
| 17:26 | <rubys> | gsnedders: view source on http://www.w3.org/TR/ |
| 17:26 | <rubys> | There's a meta link |
| 17:28 | <rubys> | oh, that's probably what jgraham was referring to. nm. |
| 17:28 | Philip` | wonders how to efficiently implement keyframe-like animation in SVG, where each frame is 100KB of independently-generated SVG code and there's typically (but not always) a lot of similarity between adjacent frames |
| 17:30 | <Philip`> | (In particular, animating http://philip.html5.org/misc/spec-links.html over the lifetime of the spec) |
| 17:44 | <gsnedders> | problem: I can't include a converted copy of <http://www.w3.org/Style/Group/css3-src/biblio.ref>; in Anolis, yet I need the same IDs to remain compat. |
| 17:46 | <Philip`> | Why can't you include that? |
| 17:46 | <gsnedders> | licensing, etc. |
| 17:46 | <Philip`> | Why do you need the same IDs? |
| 17:46 | <gsnedders> | compat. with existing documents |
| 17:47 | <Philip`> | Are there practical compatibility considerations? |
| 17:47 | <gsnedders> | seeming people like Lachy want to use it for docs they already edit, yes |
| 17:47 | <Philip`> | (i.e. do documents unavoidably rely on those specific IDs, or something?) |
| 17:47 | <gsnedders> | The IDs isn't the problem. |
| 17:48 | <gsnedders> | It's including everything in that file when it is rather long that is. |
| 17:48 | <gsnedders> | It contains really random things. |
| 17:48 | <gsnedders> | not that you can see that :) |
| 17:56 | <BenMillard> | gsnedders, maybe you could contact relevant staff at W3C about what you want? |
| 17:56 | <gsnedders> | BenMillard: I don't really want to use Refer anyway, so it isn't particularly helpful |
| 18:14 | <gsnedders> | BenMillard: Also, I shouldn't have this document at all, so contacting the relevant staff may not be the best move :) |
| 18:17 | <Philip`> | But mentioning in public logged IRC that you have illicitly gained access to it is a good move? :-) |
| 18:17 | <gsnedders> | :P |
| 18:18 | <gsnedders> | Philip`: I've implied often enough that I have got at the css3 postprocessor stuff :P |
| 19:20 | <Lachy> | gsnedders, it's not really a problem that you have a copy of that stuff. Bert really wouldn't mind. |
| 19:20 | <gsnedders> | Lachy: He knows I do. |
| 19:21 | <Lachy> | ok |
| 20:11 | <Lachy> | it would be nice if some people read the spec before making absurd, non-sensical comments about it: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017432.html Not after: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017434.html |
| 20:12 | <Lachy> | (FYI, in that first mail, he totally screwed up the quoting, but I think his comments start after the " ~TJ" signature. Everything before that is quoted.) |
| 20:18 | <jgraham> | Lachy: The first email suggests that he did read the spec. He may even have a legitimate piece of feedback |
| 20:23 | <Hixie> | the idea of pointing out the login form is that a bot that knows the name-value mapping of the fields in the form can then fill it in and submit it without needing to know the current url of the login form itself |
| 20:23 | <Hixie> | it may not be particularly useful |
| 20:29 | <Lachy> | Hixie, if the form only contains 1 text input and 1 password input, then a bot could take a fairly reasonable guess as to what each one is for |
| 20:30 | <Hixie> | yup |
| 20:31 | <Lachy> | but still, the value of the feature is still questionable since the bot could just as easily be manually told which form to submit when given the credentials |
| 20:33 | <Lachy> | jgraham, I couldn't find anything Pentasis wrote in the first email that made any sense, let alone suggests he read the spec |
| 20:33 | <jgraham> | "But, I will concede to the fact that this may make things more difficult. But in that case I would ask for the definition of the spec to be changed from "The time element represents a date and/or a time." into something more restricting and exact which at least represents the limitations of this element that are presented in this discussion." |
| 20:35 | <jgraham> | So his acionable feedback is "change the definition of the <time> element to something like 'The time element represents a date and/or time that can be expresed on a gregorian calendar' |
| 20:37 | <jgraham> | except that is not a sufficient constraint |
| 20:38 | <jgraham> | anyway I don't know if it is worth making the change but it is not obviously crazy |
| 20:43 | <Lachy> | ok, fair enough. I guess I missed that bit after being stunned by his suggestions for setting the "base time" (whatever that is) to the big bang |
| 20:44 | <Hixie> | that does seem a little premature |
| 20:45 | <jgraham> | Oh that bit was crazy. AFAICT he was suggecting something like <time base="Death of Joan of Arc">5 seconds</time> to represent 5 seconds after the moment of death of Joan of Arc |
| 20:46 | jgraham | wonders if users actually do have problems with <input placeholder> type designs |
| 20:47 | jgraham | has always found that they are used in situtations where the purpose of the conrol can be stored in short term meory for long enough to use the in put correctly |
| 20:54 | <BenMillard> | jgraham, I've seen placeholder text used instead of labelling text |
| 20:54 | <BenMillard> | when you enter several values in a form which does that throughout, it makes for a fun memory exercise :) |
| 20:55 | <jgraham> | Ah, OK I can see that it can be abused, but I have only encountered it in situations where it was easy to remember the point of the field |
| 20:56 | <Hixie> | yeah it's easily abusable but definitely has cases where it is useful |
| 20:56 | <Hixie> | it's mostly for discovery |
| 20:57 | <gsnedders> | See <http://habariproject.org/en/user/login>;, and the markup of that |
| 20:57 | <BenMillard> | jgraham, I've been noodling with the Table Inspector interface and came up with this: http://projectcerbera.com/!dev/table-inspector/ |
| 20:57 | <BenMillard> | (I broke parts of the JS by changing the types of elements) |
| 20:59 | <gsnedders> | BenMillard: You came up with the default Apache file listing? Wow. |
| 20:59 | <BenMillard> | gsnedders, new.html is the actual interface |
| 21:00 | <gsnedders> | BenMillard: :) |
| 21:00 | <jgraham> | BenMillard: It's nicer than anyhing I managed |
| 21:00 | <BenMillard> | jgraham, take as much/little as you want from it if you decide to update the real inspector |
| 21:00 | <jgraham> | BenMillard: I will |
| 21:01 | <BenMillard> | jgraham, my /!dev folder is blocked in robots.txt, so it shouldn't start outranking you in search engines :) |
| 21:01 | <BenMillard> | reducing the amount of vertical height was my main goal in the new interface |
| 21:03 | <BenMillard> | oh, and I moved the CSS and JS to external resources so they can be cached for frequent users |
| 21:05 | <Lachy> | Hixie, in the definition of Interactive Content, it says "Certain elements in HTML have an activation behavior, which means the user agent should allow the user to manually trigger them in some way, for instance using keyboard or voice input (though not mouse clicks, which are handled above)" |
| 21:06 | <Lachy> | can you make "though not mouse clicks, which are handled above" a link to wherever that's referring to? |
| 21:06 | <Hixie> | can you send mail? i'm about to be afk |
| 21:06 | <Lachy> | ok |
| 21:07 | <gsnedders> | Hixie: Lies! You're typing on your keyboard! |
| 21:08 | <Lachy> | gsnedders, he said "about to be", meaning soon, not presently |
| 21:11 | <gsnedders> | Oh, I can't read. |
| 22:14 | Hixie | ponders <input type=submit novalidate> |
| 22:36 | <Hixie> | i don't know whether to do <input type=submit novalidate> yet or whether to tell people to use form.submit() for now and add it later |
| 22:36 | <Hixie> | any opinions either way? |
| 22:37 | <Dashiva> | So there are people asking for it right now? |
| 22:40 | <jgraham> | What is the use case? |
| 22:41 | <Dashiva> | Saving a partially completed form was one |
| 22:43 | <jgraham> | Can you do that entirely without scipt assuming a novlidate attribute? |
| 22:44 | <Dashiva> | No script on the client side, at least |
| 22:45 | <jgraham> | So you have two buttons, one marked save and one marked submit? |
| 22:47 | <jgraham> | I guess it is a rther low cost feature since it is not doing something rather than doing something extra |
| 22:51 | <Hixie> | true |
| 22:51 | <Hixie> | the use case is saving the form, yeah |
| 22:53 | <Hixie> | also a "preview" button, and buttons that do server-side filling of fields without submitting the whole thing |
| 22:53 | <Hixie> | i guess i'll add novalidate |
| 22:53 | <Hixie> | you have about an hour to come up with a better name than "novalidate". :-) |
| 22:53 | <Hixie> | bbl |
| 23:50 | <BenMillard> | Hixie, calling it skipvalidity (which could be authored as skipValidity in the document) seems more consistent with the use of "validity" and "fooValidity()" and "ValidityFoo" for things in The Constraint Validation API: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-constraint-validation-api |
| 23:53 | <BenMillard> | ignorevalidity (ignoreValidity) fits the above and fits the naming of "ignoreCase" and the convention for saying "UAs must ignore foo" |