| 09:27 | <yecril71> | I think making confirm() throw on interrupt would be both user-friendly and implementation-friendly. |
| 09:27 | <yecril71> | It would not address all cases of abuse but it would be good enough for the average case. |
| 09:46 | <Hixie> | if the idea is to stop abuse, then the average case is automatically whatever isn't addressed |
| 14:36 | <annevk5> | http://intertwingly.net/blog/2008/12/15/Co-Chair-HTML-WG interesting |
| 14:41 | <annevk5> | rubys, congrats! |
| 14:42 | zcorpan | wonders what DanC will do |
| 14:43 | <rubys> | annevk5: thx! |
| 14:44 | <takkaria> | zcorpan: I thought that his funding for doing W3 work had dried up, or something along those lines |
| 14:45 | <zcorpan> | takkaria: ok |
| 14:49 | <MikeSmith> | DanC's still putting time into the group |
| 14:51 | <rubys> | I'm sure that I will lean a lot on DanC and Mike and Chris too for help. In particular, I don't know a lot about W3C processes. |
| 14:54 | MikeSmith | flinches involuntarily at mention of the word "processes" |
| 14:54 | <smedero> | MikeSmith: There was talk (@TPAC) of making some of the internal W3C documents on processes and such available to the public... how's that moving along? (or, are you even in the loop on such things) |
| 14:57 | <smedero> | I thought it might be good to have material like that available for educational purposes to non-members... as the html-wg spends a lot of cycles churning through perceived process issues (when I suspect it is much-to-do-about-nothing.) |
| 15:00 | <jgraham> | smedero: So, to paraphrase "the html-wg ... it is a much-to-do-about-nothing" ;) |
| 15:00 | <smedero> | yeah. :-/ |
| 15:01 | <smedero> | in the past i've had occasional blips of free cycles (hard to make as a working parent of a two year old) and then you open up the public-html firehose and it sucks the life out of you. |
| 15:02 | <smedero> | that said |
| 15:02 | <smedero> | i've pretty much learned to turn my attention to things like http://lists.w3.org/Archives/Public/public-html-commits/ |
| 15:02 | <smedero> | or twitter.com/whatwg |
| 15:02 | <smedero> | or this channel |
| 15:07 | <MikeSmith> | shepazu: we don't really have an internal W3C documents to de-classify. what there is really is the W3C Process doc, and that's public - |
| 15:07 | <MikeSmith> | http://www.w3.org/Consortium/Process/ |
| 15:08 | <MikeSmith> | plus we have this big book about gangsters in Chicago during the Prohibition era that we left over by some visitors to our planet many years ago |
| 15:10 | <smedero> | MikeSmith: I thought the www.w3.org/Guide was going to be non-member. |
| 15:10 | <smedero> | Not sure where the TPAC plenary IRC logs are but there should be a reference in there about this. |
| 15:13 | <smedero> | ahh |
| 15:13 | <smedero> | here it is |
| 15:13 | <smedero> | http://www.w3.org/2008/10/GuideBook.html |
| 15:13 | <karlcow> | shall we expect Ness, Youngfellow, Rossi, Flaherty, Allison, Hobson, Rossman |
| 15:14 | <karlcow> | smedero: most of the resources are Member only |
| 15:15 | <smedero> | From the TPAC logs though |
| 15:15 | <smedero> | "14:37:34 [olivier] |
| 15:15 | <smedero> | [note from #tpac: the newly reborn guidebook will be made public, in order to help contributors in public WGs and IGs too. See the draft @" |
| 15:15 | <smedero> | via: http://www.w3.org/2008/10/22-tp-irc |
| 15:16 | <Philip`> | smedero: Are you suggesting that this channel is not a firehose that sucks the life out of you? I suppose we need to work harder at encouraging pointless chat here |
| 15:16 | Philip` | 's IRC logs for this channel are 22MB, which indicates quite a lot of time spent reading :-/ |
| 15:20 | <rubys> | How many bytes are left after you remove all of the "xyzzy entered the room" type messages? |
| 15:20 | <billyjackass> | smedero: sorry, my network connection gone into vapor lock |
| 15:20 | <billyjackass> | I typed this before I realized I was talking to myself: |
| 15:20 | <billyjackass> | <MikeSmith> smedero: I don't remember discussion about making that non-member, but I have to say that looking over it, I can't see much there that seems like it really needs to be member-only |
| 15:20 | <billyjackass> | <MikeSmith> I do see a few things that aren't so up-to-date... e.g., a link to "W3C XML Specification DTD (XMLspec), well-supported by Norman Walsh." |
| 15:20 | <billyjackass> | <MikeSmith> I don't think Norm would want it being advertised that he's the support resource for XMLspec |
| 15:20 | <billyjackass> | <MikeSmith> I'm not sure he's even using XMLspec any longer himself |
| 15:20 | <billyjackass> | <MikeSmith> anyway, perhaps part of the reason for not flipping the switch on making it public is that somebody'd need to go in there and review stuff like that and bring it up to date |
| 15:20 | <billyjackass> | <MikeSmith> definitely "somebody" in the sense of "not me" |
| 15:21 | <smedero> | hehehehe |
| 15:22 | <billyjackass> | hmm, http://www.w3.org/2008/10/GuideBook.html says, "This page is Member-only".. but it's a liar |
| 15:27 | <rubys> | Lachy: I've scrolled back in the archives and caught up... you have concerns? Care to discuss? |
| 15:31 | <Philip`> | rubys: 14MB if I strip all that out, so it's still quite a bit |
| 15:32 | <Philip`> | (and 12MB if I remove timestamps and usernames) |
| 15:33 | <Philip`> | (and 4.5MB if I then gzip it, so I guess we're not repeating ourselves too much) |
| 15:33 | <jgraham> | Philip`: UTF-8? |
| 15:33 | <Philip`> | jgraham: Of course |
| 15:33 | <Philip`> | (Well, I assume it is) |
| 15:34 | <Philip`> | (and nobody talks in Unicode enough to make a real difference) |
| 15:34 | <jgraham> | Philip`: It would make a difference if it was UTF-32 |
| 15:34 | <Philip`> | (particularly since I've already got a margin of error of about 1024*1024/1000*1000 when I'm reporting these MB values) |
| 15:34 | <Philip`> | jgraham: True |
| 15:34 | <Philip`> | but irssi is not totally insane :-) |
| 15:38 | <Lachy> | rubys, my general concern is that you could abuse your power as chair to overrule the editor to get your own way, especially on controversial issues, rather than remaining objective and basing decisions on evidence. |
| 15:41 | <smedero> | Lachy: From my POV at least, Sam's actions in other standards bodies and open source software projects don't suggest that such behavior is typical for him. |
| 15:44 | <smedero> | (that is, abusing power) |
| 15:44 | <Philip`> | Cloud computing people really need to work out a better way of advertising their CPU offerings - it's quite hard to compare "1 EC2 Compute Unit" ("equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor"), a quarter of "1 Xeon core (equivalent to a P4 2.0 chip)", and "1 CPU" |
| 15:44 | <Philip`> | The first of those is sufficiently detailed, but then it kind of goes downhill |
| 15:53 | Philip` | decides instead to compare the offerings based inversely on the number of stock photos of smiling women and reflections on their web site, and EC2 wins |
| 16:02 | <rubys> | Lachy: I'm back (sorry -- had to take a call). I'm pleased with smedero's comments. |
| 16:02 | <rubys> | I don't believe that leaders that abuse their power work last very long |
| 16:03 | <Lachy> | rubys, right. |
| 16:03 | <Lachy> | let's see how long you last then :-) |
| 16:05 | <BenMillard> | rubys, have you published a list of what specific aspects you consider to be "overlap" between XHTML2WG and HTMLWG? |
| 16:06 | <BenMillard> | if not, doing so might alleviate some of the FUD :) |
| 16:07 | <yecril71> | Why are data-attributes better than scripts? |
| 16:08 | <yecril71> | Do they make it through the sanitizer or what? |
| 16:08 | <rubys> | my main concern is the "core vocabulary" |
| 16:10 | <takkaria> | yecril71: they're attributes for use in scripts, so I don't quite understand what you mean |
| 16:10 | <yecril71> | Instead of saying data=attribute="sometext" |
| 16:10 | <yecril71> | I would rather say <SCRIPT TYPE="text/plain" >sometext</SCRIPT > |
| 16:10 | <takkaria> | well, they don't achieve the same thing |
| 16:11 | <Philip`> | yecril71: How would you associate that script with an element? |
| 16:11 | <yecril71> | firstChild |
| 16:12 | <yecril71> | (or, for empty elements, nextSibling) |
| 16:13 | <Philip`> | yecril71: data-* would be associated with an element like <h1 data-reflection-colour="#ff00ff" data-reflection-height="20">My Page</h1> - how would you write something like that with <script>? |
| 16:15 | <yecril71> | reflection=colour=#FF00FF&reflection-height=20 |
| 16:15 | <yecril71> | reflection-colour=#FF00FF&reflection-height=20 |
| 16:15 | <takkaria> | as in <h1><script type="text/plain">reflection-color=#FF00FF&reflection-height=20</script>My Page</h1>? |
| 16:16 | <yecril71> | That is my idea, although I would rather use text/xml. |
| 16:16 | <takkaria> | because doing it that way makes it harder to use, since everyone has to write their own parser and serialiser to write to the <script> tag |
| 16:17 | <takkaria> | also, for elements which start off with no data- attributes and get some during script execution, scripts would have to create an element and insert it rather than just setting an attribute |
| 16:18 | <yecril71> | They would rather change an existing SCRIPT element, that would be provided specifically for the purpose. |
| 16:18 | <Philip`> | And you'd have to do something different for empty elements like <hr>, or for elements which can only contain text like <script> or <style> or <textarea> |
| 16:19 | <yecril71> | hr: nextSibling |
| 16:19 | <yecril71> | Script content is usually expressive enough; there is no need to hook additional data into the element. |
| 16:19 | <Philip`> | That sounds like an awful lot of effort and special-casing for no added value compared to just using attributes |
| 16:20 | <yecril71> | <textarea > can be served by input[type="hidden"] |
| 16:20 | <Philip`> | (and using <script> for storing data rather than script code seems like a hack) |
| 16:20 | <Philip`> | ((though it's a hack that HTML5 explicitly allows)) |
| 16:20 | <yecril71> | Except that noone is really going to do that for all the elements at the same time. |
| 16:20 | <takkaria> | but if you want to set attributes on elements, it seems much more sensible to set attributes on elements rather than create/maniplate the text value of various different hidden elements differently depending on the element you're manipulating |
| 16:21 | <yecril71> | But these attributes are only relevant to a script, arent�t they? |
| 16:22 | <yecril71> | So it seems natural to use SCRIPT for script data. |
| 16:23 | <yecril71> | Most programming languages allow both code and data to be specified, with Pascal as a notable exception. |
| 16:23 | <takkaria> | that's one argument, but if you look at what a pain in the arse doing it that way is compared to setting attributes on elements, perhaps you'll see why the latter is codified in the spec |
| 16:24 | <yecril71> | So is the former, I only asked about the advantages of it. |
| 16:24 | <takkaria> | not to mention that if you tell people to use an overcomplicated system when they could just set attributes, they'll just set attributes anyway, since it will be more efficient |
| 16:25 | <Philip`> | Looking at some of the blog comments from when data-* was added to the spec, it seems quite a lot of people were already using custom attributes to store element-specific data |
| 16:25 | <Philip`> | (and I'd done that on two separate HTML application things too) |
| 16:26 | <Philip`> | so it's nice to pave that cowpath :-) |
| 16:26 | <yecril71> | It was my first idea when I encountered this problem but then I realized I can do it more consistently. |
| 16:27 | <yecril71> | I am not questioning them being supported; they are just not better from my POV. |
| 16:28 | <yecril71> | So I was interested if anybody here actually considers them better and why. |
| 16:29 | <yecril71> | And parsing a query string should really be on the DOM, IMHO. |
| 16:29 | <yecril71> | Something like record = document.parseQuery(query). |
| 16:30 | <zcorpan> | decodeURIComponent? |
| 16:30 | <zcorpan> | hmm maybe not |
| 16:30 | <yecril71> | That does not return an arbitrary record. |
| 16:32 | <takkaria> | but parsing/serialising will be very slow compared to setting attributes |
| 16:33 | <yecril71> | It depends what the script really wants to do with the data. |
| 16:34 | <yecril71> | It can actually be quicker than going through a module boundary. |
| 16:34 | <yecril71> | (which is required to access a DOM property from script) |
| 18:22 | <MathiasBynens> | Oi |
| 18:26 | <MathiasBynens> | I was wondering if it's possible to use horizontal scrollbars to scroll through a list of images. Similar to http://monsieurlagent.com/works.php (after clicking one of the navigation links on the left), but using CSS instead of an IFRAME. Any ideas? |
| 18:27 | <MathiasBynens> | The only solution I see at the moment, is giving the parent element of the images a fixed width of x pixels, but that's not very flexible. |
| 18:28 | <Dashiva> | How would it trigger scrolling if it didn't have a set width? |
| 18:33 | <Dorward> | MathiasBynens: white-space: nowrap; perhaps? |
| 18:33 | <Philip`> | MathiasBynens: Using something like <div style="overflow: auto">? |
| 18:37 | <MathiasBynens> | Thanks Dorward! Exactly what I was looking for. :$ |
| 18:39 | <MathiasBynens> | Philip: Yeah, you're right as well. The combination of overflow: auto and white-space: nowrap applied on the element containing the list of images did the job. |
| 18:39 | <MathiasBynens> | Thanks everyone! |
| 22:23 | <heycam> | oh i only just noticed the pretty stars in the margin |
| 22:23 | <Hixie> | they're temporary |
| 22:24 | <Hixie> | just a proof of concept really |
| 22:24 | <heycam> | in the end you won't typographically distinguish rfc2119 stuff? |
| 22:24 | <Hixie> | i doubt it |
| 22:25 | <Hixie> | i'm not convinced it helps |
| 22:25 | <Hixie> | that's what i was trying to test with the current changes |
| 22:25 | <heycam> | it probably doesn't, if you don't reuse those rfc2119 keywords in the regular sense |
| 22:25 | <Hixie> | yeah |
| 22:25 | <heycam> | but the stars do look pretty against the whatwg green :) |
| 22:25 | <Hixie> | oh it looks cool, certainly |
| 22:25 | <Hixie> | christmassy and everything |
| 22:25 | <heycam> | haha |
| 22:26 | <Hixie> | i've had people criticise the spec for being "as colourful as a christmas tree" before -- i thought this would be a fitting response |
| 22:26 | Hixie | isn't a christmas fan, but sees nothing wrong with making the spec colourful |
| 22:26 | <heycam> | judicious use of colour is a good thing |
| 23:02 | <jacobolus> | what would this mean, practically? "each of us personally would like to see the XHTML2 and HTML groups brought together or at least the overlaps removed." |
| 23:02 | <jacobolus> | in http://intertwingly.net/blog/2008/12/15/Co-Chair-HTML-WG |
| 23:03 | <jacobolus> | is that just xhtml2 guys being sad at being irrelevant, and wanting to do something useful? |
| 23:13 | <Hixie> | i dunno, ask rubys :-) |
| 23:14 | <Hixie> | oh that reminds me |
| 23:14 | <Hixie> | rubys: i just added the following to that status document: |
| 23:14 | <Hixie> | - the xhtml2 wg has an outstanding action item to suggest some text |
| 23:14 | <Hixie> | for our "relationship with xhtml" section |
| 23:15 | <Hixie> | oh also, the w3c team (specifically plh) has an action to get the spec's license changed to something more open to reuse and derivations (e.g. creative commons) |
| 23:16 | <Hixie> | updated the whatwg.org/status-2008-12 document |
| 23:16 | <Hixie> | jacobolus: (i think rubys said he had a meeting or something, so he might not be around to respond) |
| 23:17 | <jacobolus> | no worries |