| 00:13 | <Hixie> | microdata in the wild: http://dragnetslegacy.blogspot.com/ |
| 00:32 | <roc> | why does the structured clone algorithm force leaf objects to be cloned? |
| 00:32 | <roc> | when they could be shared? |
| 00:35 | <roc> | for example if you have an array of N references to the same ImageData object, structured clone gives you back an array with N different ImageData objects |
| 01:02 | <Philip`> | c14n is far too much fun |
| 06:06 | <hsivonen> | looks like the SVG WG is pondering extending DOM Core: http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API |
| 06:07 | <heycam> | hsivonen, ideally, such generic extensions would go in dom core |
| 06:17 | <othermaciej> | my kingdom for someone to edit Web DOM Core |
| 06:17 | <heycam> | apple's a big company, surely you have people |
| 06:31 | <hsivonen> | the concept of having on-default graphs seems like an upcoming interop disaster: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0144.html |
| 06:31 | <hsivonen> | s/on-default/non-default/ |
| 06:35 | <othermaciej> | heycam: the number of people who are capable of doing such a thing, willing to do so, and can be spared from other tasks, is pretty small |
| 06:36 | <othermaciej> | hsivonen: whoah |
| 06:41 | <othermaciej> | hsivonen: if they make xmlns declarations for prefixes optional and define a hardcoded or registry-based list of predefined prefixes, I won't complain |
| 09:08 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=4063 |
| 09:08 | <zcorpan__> | http://forums.whatwg.org/viewtopic.php?t=4063 |
| 09:11 | <drunknbass> | heh, my little game engine is coming together nice |
| 09:11 | <drunknbass> | and renders good |
| 09:13 | <Philip`> | Is it fast enough now? :-) |
| 09:14 | <drunknbass> | haha yea |
| 09:15 | <drunknbass> | http://dl.getdropbox.com/u/890870/multitouchpipes.mp4 |
| 09:15 | <drunknbass> | it runs really fast on device too |
| 09:15 | <MikeSmith> | drunknbass: but can it beat box? A lot of MCs have some decent mike skills but beatboxing is what really separates the men from the boys. |
| 09:15 | <drunknbass> | thats just me getting the multi touch manager working with my game objects |
| 09:19 | <annevk2> | http://www.w3.org/mid/17E341CD-E790-422C-9F9A-69347EE01CEB⊙if is both funny and true |
| 09:19 | <annevk2> | especially the feed autodiscovery example is very nice |
| 09:21 | <hsivonen> | annevk2: what's the funny part? |
| 09:22 | <annevk2> | the contrast I think |
| 09:24 | <MikeSmith> | what I conclude for this is to get real work done, we clearly need more Joes in basements. |
| 09:24 | <hsivonen> | annevk2: did my other email to www-tag this morning make sense? |
| 09:25 | <MikeSmith> | following the Field of Dreams approach, maybe if we build more basements we will get more Joes and thus more good specs. |
| 09:26 | <drunknbass> | anyone know anything about the pre? |
| 09:29 | <Philip`> | MikeSmith: How many more basements do you think the world can accommodate? |
| 09:30 | <MikeSmith> | drunknbass: I don't know much but would be interested in hearing what your question is. |
| 09:30 | <MikeSmith> | drunknbass: one thing I've been told is that the UI seems to be noticeably more responsive than UI on the iPhone. so my question is, I would like to know how they did that. |
| 09:30 | <drunknbass> | just curious if canvas is supported |
| 09:30 | <MikeSmith> | drunknbass: I mean in terms of scrolling speed and such |
| 09:30 | <drunknbass> | no the ui is nowhere close |
| 09:30 | <Philip`> | What browser engine does it use? |
| 09:30 | <MikeSmith> | ah, OK |
| 09:30 | <drunknbass> | the whole ui experience is horrible |
| 09:30 | <MikeSmith> | Philip`: webkit |
| 09:31 | <drunknbass> | the browser itself doesnt seem to support canvas |
| 09:31 | <drunknbass> | but i thought native apps did |
| 09:31 | <drunknbass> | i just havent gotten around to witing any code for it yet |
| 09:31 | <MikeSmith> | drunknbass: well, that's disappointing.. from what I was told, I had been hoping they had figured out some magic |
| 09:31 | <drunknbass> | nope, ive been devving for iphone almost 2 years |
| 09:31 | <drunknbass> | the pre is nowhere close |
| 09:31 | <MikeSmith> | drunknbass: have you installed the SDK and tried it out at all |
| 09:32 | <MikeSmith> | (the Pre SDK I mean) |
| 09:32 | <drunknbass> | i have the palm sdk but havent written any palm specific code yet, was getting a basic canvas based engine going and testing in iphone safari |
| 09:32 | <annevk2> | hsivonen, haven't read that one yet |
| 09:32 | <drunknbass> | and my stuff works well in iphone so far |
| 09:32 | <MikeSmith> | Philip`: the world also needs more basements, with wood paneling, and beanbag chairs |
| 09:33 | <hsivonen> | when did Pre branch from WebKit trunk? |
| 09:33 | <MikeSmith> | drunknbass: have you tried out and Android development? |
| 09:33 | <drunknbass> | nope, ive been waiting till android actually was looking brighter |
| 09:33 | <drunknbass> | which seems to be now |
| 09:35 | <drunknbass> | so im waiting on the moto cliq to buy a device, then ill get a sholes when thats out since its gonna be a beast |
| 09:35 | <MikeSmith> | drunknbass: I live in Japan and 3rd-party Android development seems to be picking up here -- Android devices for Docomo now available |
| 09:35 | <drunknbass> | oh cool.. yea i put it off cause i hate java |
| 09:35 | <annevk2> | hsivonen, yes |
| 09:36 | <drunknbass> | but it seems they have a ndk now so that looks interesting |
| 09:37 | <MikeSmith> | drunknbass: I thought the NDK only let you build components -- libraries or whatever -- but that the actual apps still need to be produced using the Java SDK |
| 09:37 | <hsivonen> | annevk2: ok. thanks |
| 09:38 | <MikeSmith> | drunknbass: the writeups I've seen about the Cliq make it sound pretty disappointing |
| 09:39 | <drunknbass> | well. the cli will be better than the g1 |
| 09:39 | <drunknbass> | but its still not iphone quality |
| 09:39 | <MikeSmith> | drunknbass: have you ever done any BREW development? |
| 09:39 | <drunknbass> | but there are no android devices that are on that level till sholes is out so its not a big deal |
| 09:39 | <drunknbass> | nope. but i did buy a book to learn it lol |
| 09:40 | <drunknbass> | i started writing java for dangerOS and hated it |
| 09:40 | <annevk2> | how ugly is the image for menu type=toolbar? |
| 09:40 | <drunknbass> | and that was the last java i touched |
| 09:40 | <annevk2> | is that really how we envision it? |
| 09:40 | <MikeSmith> | drunknbass: was dangerOS J2ME? |
| 09:40 | <drunknbass> | i think so |
| 09:41 | <annevk2> | Hixie, is type=toolbar for system menus or something else? |
| 09:41 | <Hixie> | it's for toolbars |
| 09:41 | <annevk2> | and would it be drawn on the page's canvas or the browser UI? |
| 09:41 | <annevk2> | the spec is really vague |
| 09:42 | <Hixie> | how is the spec vague |
| 09:42 | <MikeSmith> | maybe you'd like Java development for mobile in a real Java SDK better (which Android has) better than J2ME |
| 09:42 | <Hixie> | there's whole sections on this |
| 09:42 | <drunknbass> | im sure once i get the hang of it ill be ok |
| 09:42 | <Hixie> | annevk2: http://www.whatwg.org/specs/web-apps/current-work/#tool-bars-0 |
| 09:42 | <drunknbass> | i just hate the initial hump to get over |
| 09:42 | <drunknbass> | esp when i feel so good writing code for mac or iphone |
| 09:43 | <drunknbass> | like learning js enough to write a game ive been in a pretty shitty mood the last week or so lol |
| 09:43 | <MikeSmith> | drunknbass: just tell yourself, It could be worse. I could be having to program in BREW. |
| 09:43 | <annevk2> | Hixie, ok, so it appears inline |
| 09:43 | <annevk2> | Hixie, I was looking for menu element in the rendering section |
| 09:43 | <Hixie> | ah |
| 09:44 | <annevk2> | Hixie, but image in the menu element section does not represent the Mac OS platform for toolbars afaict |
| 09:44 | <Hixie> | (sorry, kinda grumpy right now, lacking in sleep) |
| 09:44 | <Hixie> | annevk2: yeah the image is a disaster |
| 09:44 | <Hixie> | annevk2: wasn't sure how to make a better one to represent that markup |
| 09:45 | <Hixie> | annevk2: i tried playing around in interface builder with little success |
| 09:45 | <annevk2> | and shouldn't we be addressing the typical dropdown menus you find on pages first? |
| 09:45 | <Hixie> | i thought this _was_ addressing that |
| 09:46 | <annevk2> | i guess maybe they can if we provide a ton of styling hooks |
| 09:46 | <hsivonen> | is Opera Mini available for Brew these days? is it an manual implementation or a Java compilation targeted at non-Java byte code and libs? |
| 09:46 | <drunknbass> | yea i swore js was the worst |
| 09:46 | <drunknbass> | but its not THAT bad |
| 09:47 | <drunknbass> | but only because i can see what im doing actually performing fairly well |
| 09:48 | <annevk2> | hsivonen, http://www.opera.com/press/releases/2007/12/06/ |
| 09:48 | <MikeSmith> | hsivonen: yeah, I think they did a BREW port of Mini, but I have not idea of how it was built |
| 09:48 | <MikeSmith> | hsivonen: takkaria might now |
| 09:48 | <annevk2> | hsivonen, no idea how much I can share about implementation details, so I'm not gonna |
| 09:48 | <MikeSmith> | *know |
| 09:49 | <hsivonen> | annevk2: OK. The press release is silent on implementation strategy |
| 09:49 | MikeSmith | notices that annevk2 was actually answering hsivonen questions while I was speculating, and will shut up now |
| 09:49 | hsivonen | recalls reading that Opera had an API wrapper for Android and not an independent port |
| 09:50 | <MikeSmith> | hsivonen: that API wrapper was a thing that translates J2ME calls to real Java SE calls |
| 09:51 | Hixie | works on ws: and wss: registrations and grumbles at the inane design of the uri/iri specs |
| 09:51 | <annevk2> | Hixie, maybe you should say in a reply to Larry that the registration process should be simplified |
| 09:52 | <Hixie> | still waiting for larry to respond to me |
| 09:52 | <Hixie> | for the last e-mail i sent |
| 09:52 | <annevk2> | review comments? |
| 09:52 | annevk2 | got replies from Martin |
| 09:53 | <Hixie> | something about how the error handling algorithms aren't quite what we need |
| 09:53 | <annevk2> | I wonder if it was because of my email to the public-html list suggesting we should include URL stuff again or some other reason... |
| 09:59 | <Hixie> | wooo, we crossed the 100 e-mail barrier |
| 10:01 | <Lachy_> | Hixie, how far below it are you? |
| 10:01 | <Philip`> | Quick, send more email so we can cross it again |
| 10:02 | <Hixie> | right at this minute i'm at 85 |
| 10:02 | <Lachy_> | Philip`, that's why I was asking how many :-) |
| 10:02 | <Hixie> | 85 e-mails remaining; 137 issues remaining; 165 bugs remaining |
| 10:02 | <jgraham_> | Now we get to see if you are cheating |
| 10:03 | <jgraham_> | Because we must reach equlibrium at some point where issues come in as fast as you can respond to them |
| 10:03 | <hsivonen> | Hixie: issues as in issues markers in the spec? |
| 10:03 | <krijnh> | Will there be a party when we/you reach 0? :) |
| 10:03 | <Hixie> | yes |
| 10:03 | <jgraham_> | (unless, I guess, you deal with issues faster than several hyundred people report them) |
| 10:03 | <krijnh> | Great! |
| 10:03 | <jgraham_> | (which is possible, so ignore me) |
| 10:03 | <Hixie> | the yes was to hsivonen :-P |
| 10:04 | <krijnh> | No, no, that's not how I read the logs! :) |
| 10:04 | <Hixie> | jgraham_: i've been responding to requests faster than they've been coming in on average for several years now |
| 10:04 | <Lachy_> | krijnh, Hixie said yes before you asked the question |
| 10:04 | krijnh | changes the logs a bit |
| 10:04 | <Hixie> | we can have a party also, if you like |
| 10:04 | <Philip`> | No, Hixie said yes after krijnh's question |
| 10:04 | <krijnh> | There :) |
| 10:05 | <Hixie> | personally i was thinking of announcing last call and going on vacation |
| 10:05 | <Philip`> | from my frame of reference |
| 10:05 | <krijnh> | Hixie: aren't you gonna wait for you Christmas bonus? |
| 10:05 | <Hixie> | christmas bonus? |
| 10:06 | <jgraham_> | Hixie: But that doesn't necessarily work once you get to a small number of outstanding items because your abilility to respond faster than stuff comes in is predictaed on there being a large volume of communication per issue |
| 10:06 | <Hixie> | i'll be back before christmas |
| 10:06 | <krijnh> | For reaching LC before Christmas! |
| 10:06 | <hsivonen> | LC in October, CR by Christmas :-) |
| 10:06 | <Hixie> | jgraham_: i just have to wait til you're all in bed, do the last few issues, announce LC, and then go to bed |
| 10:06 | <Hixie> | christmas 2012, maybe |
| 10:07 | <krijnh> | You can redefine Christmas using a willful violation! |
| 10:07 | <krijnh> | No idea what problem that solves, but heck |
| 10:07 | <Philip`> | Someone needs to set up a script that we can submit feedback to, and then it will forward one message to the mailing list every ten minutes |
| 10:07 | <hsivonen> | krijnh: it would be backwards-incompatible |
| 10:08 | <krijnh> | hsivonen: I need data for that |
| 10:08 | <Philip`> | hsivonen: It wouldn't be if you only redefine the meaning of Christmas for years >= 2009 |
| 10:08 | <Philip`> | I suppose it would still be incompatible with backwards people who haven't adopted our new system, though |
| 10:09 | <krijnh> | So anyway, annevk2: let's organize a party with Fronteers when HTML5 reaches LC :) |
| 10:09 | <Lachy_> | where should we hold this party? |
| 10:09 | <krijnh> | In NL, of course |
| 10:10 | <Lachy_> | ok. I do need to visit NL one day soon |
| 10:10 | <Lachy_> | before going to the US |
| 10:10 | <krijnh> | Before the TPAC you mean? |
| 10:11 | <annevk2> | krijnh, I should be in NL between oct25 and nov2 or so |
| 10:11 | <Lachy_> | it might have to be after TPAC, since I intend to crash at Anne's place and finding a time when he's at home between now and TPAC isn't going to be easy |
| 10:11 | <Lachy_> | unless I go then |
| 10:12 | <MikeSmith> | hsivonen: I'm writing a message to the jena-dev list about AryehGregor's http://bugzilla.validator.nu/show_bug.cgi?id=641 bug report |
| 10:12 | <MikeSmith> | hsivonen: and I wanted to ask something |
| 10:13 | <MikeSmith> | hsivonen: which is, does v.nu do any pre-processing of any kind on IRIs before passing them to the Jena IRI library for checking? |
| 10:13 | <hsivonen> | IIRC, not for http |
| 10:13 | <MikeSmith> | OK |
| 10:13 | <hsivonen> | I can't recall what I did with javascript: |
| 10:14 | <MikeSmith> | do you have any insight at all on that error? it seems like a bug in the Jena library, right? |
| 10:14 | <hsivonen> | is the character classified as a compatibility character in Unicode? |
| 10:15 | <hsivonen> | grr. someone is shaking the house |
| 10:15 | <MikeSmith> | hsivonen: err, I'm not sure. I guess I should check that first |
| 10:15 | <hsivonen> | hrm. so hard to keeps hard disks safe from vibrations |
| 10:15 | MikeSmith | googles to figure out how to check if something is a compatibility character or not |
| 10:15 | <hsivonen> | someone is digging a hole in the ground right outside my window |
| 10:16 | <hsivonen> | MikeSmith: I'd expect there to be an RFC somewhere that has a SHOULD NOT for compatibility chars |
| 10:16 | <hsivonen> | MikeSmith: maybe it's silly, but I'd expect the Jena check to come from someone |
| 10:16 | <MikeSmith> | OK |
| 10:16 | <MikeSmith> | r12a told me that there is some normalized equivalent for that character |
| 10:16 | <hsivonen> | so far I've always been able to trace Jena IRI lib behavior to an RFC |
| 10:17 | <MikeSmith> | hmm, OK |
| 10:18 | <hsivonen> | 5.3.2.2. Character Normalization |
| 10:18 | <hsivonen> | in RFC 3987 looks interesting |
| 10:18 | <boblet> | Hixie: re: using <dl> to mark up conversations a la HTML4, what was the reason that was bad? |
| 10:19 | <Hixie> | same reason that using <em> for citations is bad |
| 10:19 | <boblet> | Hixie: I remember it as abuse of <dl>, rather than use of <dt>/<dd>…? |
| 10:19 | <Hixie> | right |
| 10:19 | <boblet> | so overloading one element with two semantic meanings is the bad thing, is that correct? |
| 10:20 | <hsivonen> | I'm not seeing anything about compatibility characters under security considerations |
| 10:20 | <Hixie> | boblet: no |
| 10:20 | <hsivonen> | but the spec mentions NFKC which doesn't preserve compatibility characters... |
| 10:20 | <Hixie> | boblet: not necessarily |
| 10:20 | <Hixie> | boblet: overloading one element for two meanings in an indistinguishable way can be a problem, though |
| 10:21 | <hsivonen> | MikeSmith: found a SHOULD! |
| 10:21 | <Hixie> | boblet: especially when the ways are somewhat contradictory (e.g. "name-value pairs" vs "dialogue") |
| 10:21 | <boblet> | Hixie: I’m wondering if given <dt>/<dd>’s recent expansion into <figure> etc, would <ol><dt><dd></ol> be feasible? |
| 10:21 | <MikeSmith> | hsivonen: http://www.eki.ee/letter/chardata.cgi?ucode=edc |
| 10:21 | <hsivonen> | section 7.5. third paragraph |
| 10:21 | <Hixie> | boblet: to mean what? |
| 10:22 | <MikeSmith> | hsivonen: .me reads RFC 3987 |
| 10:22 | <boblet> | Hixie: as a substitute for <dialog><dt><dd></dialog> |
| 10:22 | <hsivonen> | MikeSmith: I take "<compat>" to mean it's a compatibility character |
| 10:22 | <boblet> | admittedly a stretch… |
| 10:22 | <Hixie> | boblet: what's wrong with <p></p> as a substitute |
| 10:22 | <boblet> | a conversation seems to call for a list ordered by time |
| 10:23 | <Hixie> | o_O |
| 10:23 | <hsivonen> | MikeSmith: I'm not taking a stance on whether the SHOULD makes sense, but it's not a Jena bug |
| 10:23 | boblet | wonders if that’s the falling off the chair emoticon |
| 10:24 | <hsivonen> | MikeSmith: one option would be disabling the treatment of SHOULD violations as errors |
| 10:24 | <MikeSmith> | hsivonen: yeah |
| 10:24 | <hsivonen> | in the datatype lib where the Jena lib is configured |
| 10:25 | <MikeSmith> | hsivonen: but it gets back to, we'd still want to warn about those at least |
| 10:25 | <MikeSmith> | so we need that warn mechanism... |
| 10:25 | <MikeSmith> | in the HTML5 datatype lib |
| 10:25 | <hsivonen> | yes... |
| 10:26 | <MikeSmith> | hsivonen: I will try to work on it next week |
| 10:26 | <hsivonen> | Hixie: did you mean to import IRI SHOULD violations into HTML5 conformance criteria? |
| 10:26 | <hsivonen> | MikeSmith: cool |
| 10:26 | <Hixie> | hsivonen: no idea |
| 10:26 | <Hixie> | hsivonen: which ones |
| 10:26 | <Philip`> | hsivonen: You should use cloud storage, so your disks are isolated from any vibrations down on the ground |
| 10:26 | <hsivonen> | Hixie: any |
| 10:27 | MikeSmith | seems to remember promising last week to work on it this week.. |
| 10:27 | <hsivonen> | Hixie: any that apply to authors that is |
| 10:27 | <boblet> | Hixie: I’m guessing that meant I’m talking crazy then, huh :) |
| 10:27 | <Hixie> | boblet: :-) |
| 10:27 | <Hixie> | boblet: i just don't understand the problem it would solve |
| 10:27 | <Hixie> | hsivonen: as a general rule i want to violate other specs as little as possible |
| 10:28 | <Hixie> | hsivonen: however, as a general rule, i'll violate them where it's necessary for compatibility or sanity |
| 10:28 | <Philip`> | boblet: http://en.wikipedia.org/wiki/o_O :-p |
| 10:28 | <Hixie> | hsivonen: dunno what else to say unless you have a more specific question |
| 10:28 | <Philip`> | (Hmm, actually that page doesn't quite describe that symbol) |
| 10:29 | <boblet> | a sanctioned way to mark up dialogs that is more semantic than <p><i class="speaker">speaker</i> statement</p> |
| 10:29 | <Hixie> | boblet: "Semantic" is not a goal |
| 10:29 | boblet | is rescued from ignorance by Philip` |
| 10:29 | <hsivonen> | Hixie: is it dumb to emit an error when Wikipedia uses ໜ in href? |
| 10:29 | <boblet> | I gotta go, |
| 10:30 | <boblet> | might email it to the list so I can be shot down in a more public forum ;-) |
| 10:30 | <Hixie> | (that is, "semantic" is a means, not an end) |
| 10:30 | <Hixie> | hsivonen: dunno |
| 10:30 | <Hixie> | hsivonen: why would it be an error? |
| 10:30 | <boblet> | Hixie: I’ll ask you about that next time I’m on… til then |
| 10:30 | <hsivonen> | Hixie: it's a compatibility character |
| 10:30 | <annevk2> | hsivonen, since you validate href= you should arguably validate CSS too :) |
| 10:31 | <Hixie> | hsivonen: those are bad right? |
| 10:31 | <Hixie> | hsivonen: i guess it should be an error then |
| 10:31 | <Hixie> | hsivonen: dunno, ask martin d or r12a |
| 10:31 | <hsivonen> | Hixie: well, the IRI spec says they are bad on the SHOULD level |
| 10:31 | <hsivonen> | Hixie: I'm not sure what the exact badness is |
| 10:31 | <hsivonen> | Hixie: except if you print the IRI and type it back in, it's ambiguous what IRI you meant |
| 10:32 | <Hixie> | hsivonen: sounds bad |
| 10:32 | <hsivonen> | actually, that's the badness |
| 10:33 | <hsivonen> | AryehGregor: would MediaWiki be helped or hindered if it used NFKC for article IRIs? |
| 10:34 | <hsivonen> | AryehGregor: maybe it could use NFKC for canonical IRIs and redirect non-NFKC IRIs to the NFKC-normalized IRIs |
| 10:34 | <annevk2> | hsivonen, IRIs should be NFC |
| 10:34 | <hsivonen> | AryehGregor: does referring to Lao Wikipedia articles in print work in practice now |
| 10:34 | <annevk2> | hsivonen, when you type in an IRI, it ought to be normalized to NFC |
| 10:34 | <hsivonen> | annevk2: the RFC encourages NFKC but allows NFC |
| 10:35 | <annevk2> | that's weird |
| 10:35 | <hsivonen> | when one types the said Lao character, does one get NFKC on the usual operating systems? |
| 10:36 | <hsivonen> | annevk2: Although there may be exceptions, newly created resource names should generally be in NFKC [UTR15] (which means that they are also in NFC). |
| 10:36 | <annevk2> | http://tools.ietf.org/html/rfc3987#section-3.1 see step 1, substep a |
| 10:36 | <hsivonen> | says RFC 3987 |
| 10:36 | <annevk2> | ah ok |
| 10:37 | <hsivonen> | Unicode ❤ |
| 10:37 | <MikeSmith> | hsivonen: fwiw, dependencies/iri-0.5/src/com/hp/hpl/jena/iri/impl/AbsLexer.java has this comment: |
| 10:37 | <MikeSmith> | 170 // compatibility char |
| 10:37 | <MikeSmith> | 171 // defn is NFD != NFKD, ... hmmm |
| 10:37 | <MikeSmith> | what does that mean? |
| 10:37 | <MikeSmith> | is it relevant? |
| 10:37 | <annevk2> | hsivonen, actually |
| 10:38 | <hsivonen> | MikeSmith: I *think* it means that character c is a compatibility character if NFD(c) != NFKD(c) |
| 10:38 | <annevk2> | "IRIs SHOULD be created by using NFC. Using NFKC may avoid even more problems; for example, by choosing half-width Latin letters instead of full-width ones, and full-width instead of half-width Katakana." |
| 10:39 | <hsivonen> | annevk2: why is that SHOULD in all caps but the one I quoted isn't? |
| 10:39 | <hsivonen> | significant or bad editing? |
| 10:40 | <hsivonen> | oh. chapter 7 is informative |
| 10:40 | <hsivonen> | way to go IETF! using "should" in informative text |
| 10:41 | <annevk2> | IETF is teh awesome |
| 10:41 | <jgraham_> | Does no one read these specs for basic things like that? |
| 10:41 | hsivonen | leaves for lunch |
| 10:42 | <MikeSmith> | http://www.eki.ee/letter/chardata.cgi?ucode=3f0 has <compat> in its Decomposition field also |
| 10:42 | <MikeSmith> | ϰ GREEK KAPPA SYMBOL |
| 10:43 | MikeSmith | wonders does that mean using a GREEK KAPPA SYMBOL in an IRI is also going to make the IRI library emit that error |
| 10:43 | <hsivonen> | MikeSmith: ANSTROM SIGN also decomposes to plain Å |
| 10:43 | <Philip`> | Seems like it's not a problem if they consistently use SHOULD in normative text, and should in informative text |
| 10:44 | <Philip`> | because then it's clear what each word means, and clear they didn't just make a simple capitalisation mistake |
| 10:44 | <hsivonen> | *ANGSTROM |
| 10:45 | <jgraham_> | Philip`: It seems like poor form to ever use RFC2119 keywords in a way that is not supposed to convey the keyword meaning |
| 10:53 | <Philip`> | jgraham_: I don't see why it's a problem if it's unambiguous, and if there's a clear consistent convention about always spelling keywords in uppercase then it seems unambiguous |
| 11:17 | <hsivonen> | hmm. it turns out that the people digging the hole outside my window are fixing my ADSL |
| 11:22 | <Hixie> | heh |
| 11:23 | <hsivonen> | it's a bit unusual that an ADSL problem is actually diagnosed to be a problem with the cable coming into the building |
| 11:35 | <erlehmann> | hsivonen, did the support at least ask you to use the original provider-crapware before doing anything ? |
| 11:36 | <hsivonen> | erlehmann: actually, the offered to reboot their end and send me a new ADSL model |
| 11:36 | <hsivonen> | s/model/modem/ |
| 11:37 | <erlehmann> | oh wow |
| 11:37 | <hsivonen> | erlehmann: but when their rebooted their end, they found something worse |
| 11:37 | <zcorpan> | the resource selection algorithm is non-trivial to understand |
| 11:37 | <hsivonen> | the guys digging the cables said they suspected water damage in the cables |
| 11:39 | <zcorpan> | although i guess it's just Hixie, the implementors, and the test case writers who need to understand it |
| 11:40 | hsivonen | has no idea what kind of diagnostics telcos have for deciding where they need to dig if a DSL line doesn't come back up normally after rebooting the provider end |
| 11:40 | <hsivonen> | also, I'm positively surprised by the effectiveness of the subcontracting chain |
| 11:40 | <hsivonen> | there are at least 4 companies acting on less than 24 hour notice to fix stuff |
| 11:42 | <jgraham_> | zcorpan: So that's like 9 people in the world? |
| 11:42 | <zcorpan> | jgraham_: yes |
| 11:43 | <jgraham_> | Oh well. I guess they can just suffer ;) |
| 11:43 | <zcorpan> | it seems i have caused a new acronym to be minted: PIPA (processing instruction with pseudo-attributes) |
| 11:43 | <zcorpan> | but one of them is me! :( |
| 11:43 | <jgraham_> | I know! |
| 11:43 | <zcorpan> | you're evil |
| 11:43 | <erlehmann> | hsivonen, i would suspect this http://en.wikipedia.org/wiki/Time-domain_reflectometer |
| 11:44 | <zcorpan> | although i guess you know what it's like, with ecmascript |
| 11:45 | <hsivonen> | erlehmann: ok. I didn't know about those |
| 11:46 | <erlehmann> | hsivonen, magic^H^H^H physics is awesome :> |
| 12:01 | Philip` | is reminded of http://jwz.livejournal.com/94645.html about debugging cables |
| 12:33 | <jgraham_> | hsivonen: I used <details> yesterday |
| 12:33 | <hsivonen> | jgraham_: how? |
| 12:34 | <jgraham_> | With javascript to do the open/close thing wrapped in an if (details.open === undefined){} |
| 12:34 | <hsivonen> | jgraham_: living dangerously |
| 12:34 | <jgraham_> | I guess |
| 12:35 | <jgraham_> | I jsut do markup for the andrenaline rush |
| 12:35 | <zcorpan> | that's when you know you're alive |
| 12:37 | zcorpan | misspells </titel> |
| 12:43 | <Lachy> | I wonder how many authors attempting to do a check like that, would fail by using == instead of ===? |
| 12:43 | <hsivonen> | http://twitter.com/ppk/status/4051901363 |
| 12:43 | <hsivonen> | it's now in three browsers isn't it? |
| 12:44 | <Lachy> | the drag and drop stuff was based on IE's implementation, wasn't it? So it's not really our fault if it sucks |
| 12:44 | <hsivonen> | Lachy: right |
| 12:45 | <Lachy> | although, I've never had a need to use it, so I don't really know whether it's good or bad. |
| 12:45 | <Lachy> | maybe I should try experimenting with it one day |
| 13:05 | <jgraham_> | Lachy: re: == vs ===; if you are using == you've already lost |
| 13:06 | <jgraham_> | s/using/ever using/ |
| 13:07 | <Lachy> | jgraham_, why? |
| 13:07 | <krijnh> | hsivonen: when are you going to integrate the new dt/dd stuff into validator.nu? |
| 13:07 | <krijnh> | (If ever) |
| 13:08 | <hsivonen> | krijnh: in Q4 unless Mike does it first |
| 13:08 | <jgraham_> | Lachy: Because it does implicit type conversion. Eventually you will get bugs |
| 13:10 | <Lachy> | yeah, you have to be careful with it, but sometimes, it's the right thing to use |
| 13:11 | jgraham_ | doubts it ;) |
| 13:14 | <Lachy> | jgraham_, as a simple example, consider a form validation script that is checking whether or not a user entered an acceptable number into a text field. |
| 13:14 | <Lachy> | It's easier to say: if (input.value >=1) than to have to explicitly convert the value to a number first |
| 13:16 | <Lachy> | oops, I meant to use ==, not >= |
| 13:18 | <jgraham_> | if (input.value === "1") is also fine |
| 13:19 | <Lachy> | not if the 1 is replaced with a variable, which is known to be calculated as a number |
| 13:20 | <Philip`> | if ((double ? input.value*2 : input.value) == 1) ... |
| 13:20 | <Lachy> | so either way, you would need to either do an explicit type conversion, or just accept the automatic conversion |
| 13:20 | <Philip`> | (Uh, is double a reserved word? Use some other variable name if so) |
| 13:20 | <Philip`> | You might not know or care what the type is |
| 13:21 | <jgraham_> | Philip`: double is a FutureReservedWord. WHich in practice means that it's probably not |
| 13:23 | jgraham_ | doesn't really understand what Philip` is trying to show. Are you expecting 2*input.value to be 2 or "11" given input.value == 1 |
| 13:23 | <Lachy> | yeah, the attempts to introduce new reserved words into a widely used language, when such reserved words have no other way to be distinguished from variables is a bit silly |
| 13:23 | <Lachy> | jgraham_, in JS, it would be 2 |
| 13:24 | <Lachy> | I don't see why anyone would expect a multiplaction of "1" to end up as "11" |
| 13:24 | <jgraham_> | Oh, I've been looking at addition too much (that prefers implicit string conversion) |
| 13:24 | <Lachy> | *multiplication |
| 13:25 | <jgraham_> | Lachy: python has 2*"1" == "11" |
| 13:25 | <jgraham_> | But it also doesn't have silly implicit type conversions for equality or addition |
| 13:25 | <Lachy> | jgraham_, that doesn't answer the question, of who on earth would *expect* such insane behaviour? |
| 13:26 | <jgraham_> | Lachy: Me, obviously |
| 13:26 | <Philip`> | jgraham_: The point is the result might be a number (due to *'s automatic conversion) or a string, so you don't know its type, and you don't really care what its type is, since you can just use == to compare and it will do what you want |
| 13:26 | <Lachy> | you're obviously not on earth then, where multiplication is a numeric operation, not string concatenation |
| 13:26 | <jgraham_> | Lachy: Seriously, if I need a string with 500 a's in it, what syntax would you suggest? |
| 13:26 | <jgraham_> | s/a/"a"/ |
| 13:27 | <Lachy> | "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" |
| 13:27 | <jgraham_> | Lachy: haha |
| 13:27 | <jgraham_> | Assume 500 is a variable that I don't know in advance |
| 13:27 | <Lachy> | what's the use case? |
| 13:28 | <cpharmston> | "a"*500 |
| 13:28 | <jgraham_> | Well I use it pretty often in python so it obviously has a use case |
| 13:28 | <jgraham_> | Nothing so thrilling that I recall it off the top of my head |
| 13:28 | <workmad3> | "a" * no_of_a |
| 13:28 | <workmad3> | (in this case, no_of_a would have the value '500') |
| 13:29 | <Lachy> | workmad3, that doesn't work in JS |
| 13:29 | <Philip`> | jgraham_: "a" x 500 |
| 13:29 | <workmad3> | not in js, no |
| 13:29 | <workmad3> | that's python |
| 13:29 | <Lachy> | I know, as jgraham_ already pointed out |
| 13:29 | <Philip`> | jgraham_: That's what Perl does, and it avoids weird overloading of '*' |
| 13:29 | <workmad3> | ah right |
| 13:29 | <workmad3> | sorry |
| 13:30 | <jgraham_> | Philip`: I still think you are better off doing an explicit type conversion for equality |
| 13:30 | <Philip`> | jgraham_: (It also uses . for concatenation to avoid weird overloading of '+', which avoids the JS bugs you get with input.value+1 etc) |
| 13:31 | <workmad3> | var lots_of_a = ""; for( var i = 0; i < no_of_a; i++) {lots_of_a += "a";} |
| 13:31 | <workmad3> | that's the best I can think of for JS |
| 13:31 | <jgraham_> | Philip`: I don't see a problem with using + to concatanate when both operands are strings |
| 13:32 | <jgraham_> | workmad3: (new Array(500)).join("a") would work |
| 13:32 | <workmad3> | ... good point |
| 13:32 | <workmad3> | but yeah, I'm with you in that I don't have a problem with + for concatenation of strings |
| 13:34 | <workmad3> | and using a . instead would mean the parser would need to be worked on as you could have some_string.some_other_string and that could be either a method call or string concatenation |
| 13:34 | <Philip`> | jgraham_: It seems reasonable in statically typed languages, where you know it's obviously concatenation, but it's confusing and error-prone in dynamically typed languages where you can't tell from the code what the '+' is doing |
| 13:35 | <jgraham_> | Philip`: What do you mean "you can't tell from the code...". Obviously you can tell if you know the types of the operands |
| 13:36 | <Lachy> | jgraham_, yeah, but you have to know the types, which doesn't work in this case:... |
| 13:36 | <Lachy> | function foo(a, b) { return a + b; } |
| 13:36 | <Philip`> | jgraham_: You don't know the types of the operands, because it's dynamic and you have to trace back the execution until some point where you can know what the type is |
| 13:36 | <jgraham_> | Right that will do different things depoending on what types a and b have |
| 13:37 | <Lachy> | yep |
| 13:37 | <jgraham_> | But it would even if each thing had a unique operator |
| 13:37 | <Philip`> | and you'll probably have to look up some API documentation to work out what type is, if it comes from a DOM API or something |
| 13:37 | <jgraham_> | because e.g. foo(3, "3") would throw |
| 13:37 | <jgraham_> | but foo(3,3) would return 6 |
| 13:38 | <Philip`> | jgraham_: The operators can do automatic type conversion, e.g. '+' converts its operands to numbers (then adds), and '.' converts its operands to strings (then concatenates) |
| 13:38 | <Lachy> | foo(3, "3") in JS would return "33" |
| 13:38 | <Philip`> | and so you never have to care whether your values are strings-of-digits or numbers, because they're treated equivalently |
| 13:39 | <jgraham_> | Lachy: I know. I was assuming a strongly, dynamically typed language |
| 13:39 | <jgraham_> | which is what I thought we were talking about |
| 13:39 | <Lachy> | using . as an operand for string concatenation, like in PHP, is a silly convention |
| 13:39 | <Lachy> | . should be used for methods, like it is in sensible languages |
| 13:40 | <Philip`> | Choose some other symbol then, as long as it's not '+' |
| 13:40 | <Lachy> | jgraham_, oh, sorry, didn't realise |
| 13:40 | <Lachy> | IIRC, VisualBasic used & |
| 13:40 | <Philip`> | Perl 6 agrees . should be used for method calls, so it's changed to ~ for string concatenation |
| 13:41 | <workmad3> | but then you're using a logic operator and the same issues apply |
| 13:41 | <Lachy> | workmad3, I know |
| 13:41 | <jgraham_> | Philip`: Sure you never have to care if you only care about not throwing at operators rather than getting the right result |
| 13:41 | <workmad3> | I can't think of a standard symbol that isn't already used |
| 13:42 | <jgraham_> | Weak typing typically just increases the distance between the bug and the error being thrown |
| 13:42 | <jgraham_> | (or prevents an error but gives an incorrect result) |
| 13:42 | <Lachy> | jgraham_, yes, but it makes things easier in the process |
| 13:43 | <Philip`> | jgraham_: If I write '1' into an input box, and my code does input.value+1, I think 2 is the right result |
| 13:43 | <Philip`> | and I'm happy for it to do automatic type conversion from strings to numbers for addition |
| 13:43 | <Philip`> | and there's no bug |
| 13:43 | <jgraham_> | Philip`: Javascript would give you '11' though |
| 13:43 | <jgraham_> | so you would be surprised |
| 13:44 | <Philip`> | jgraham_: Sure, which is why JS is silly, but Perl is sensible because it will always give 2 |
| 13:45 | jgraham_ | notes that Perl code is not typically held up as being easy to understand |
| 13:45 | <Philip`> | and I don't have to care whether the inputs are strings-of-digits or numbers |
| 13:45 | <jgraham_> | Philip`: In this micro example you don't. In almost any real world example you would |
| 13:45 | <Lachy> | I like CSS's approach to string concatentation in the content property: content: "a" "b"; |
| 13:45 | <Lachy> | no need for an extra symbol |
| 13:45 | <Philip`> | jgraham_: There's no implication between "some Perl code is hard to understand" and "if X is a feature that exists in Perl, then X makes programs hard to understand" |
| 13:47 | <jgraham_> | Philip`: Not using deductive logic no. But it does suggest you should think about whether X is in fact a feature that makes programs hard to understand |
| 13:47 | <Philip`> | jgraham_: Sure, and I've thought about it, and it doesn't :-p |
| 13:47 | <jgraham_> | Philip`: Yes it does :p |
| 13:48 | <Philip`> | I've written real bugs because of JS's + doing concatenation when I expected addition |
| 13:48 | <jgraham_> | Right. So if it did neither you would be fine and your error console would tell you exactly where the bug was |
| 13:48 | <Philip`> | and Perl prevents those bugs, because it doesn't surprisingly switch from addition to concatenation depending on the run-time state of its variables |
| 13:49 | <Philip`> | I'm not sure if you're disagreeing that Perl is better than JS, or if you're just saying that throwing exceptions instead of automatically converting type would be even better |
| 13:49 | <jgraham_> | (assuming you had different types of variables) |
| 13:49 | <Philip`> | s/type/types/ |
| 13:49 | <jgraham_> | I'm saying that throwing exceptions when the variables are different types is probably the best approach |
| 13:50 | <jgraham_> | At least for addition and equality |
| 13:50 | <jgraham_> | (and subtraction and division, obviously) |
| 13:50 | <Lachy> | Philip`, how do you feel about operator overloading in C++, which allows + (and other operators) to be overridden to do basically anything with a given object? |
| 13:50 | <Philip`> | That seems contrary to design of all dynamically typed languages I'm aware of, which all treat strings-of-digits as equivalent to numbers in almost all cases |
| 13:51 | <jgraham_> | Er, sorry, I don't mean "throw for equality", I mean "return False for equality" |
| 13:51 | <jgraham_> | Philip`: Python doesn't |
| 13:52 | <Philip`> | jgraham_: Oh, I forgot Python :-( |
| 13:52 | <takkaria> | Lachy: that is evil, it really screws up the ability to understand what's going on |
| 13:53 | <Philip`> | Lachy: I think it's useful when it's used carefully, e.g. it's useful that std::string overloads + for concatenation instead of requiring a method call or special parser magic (like in Java) |
| 13:54 | <Philip`> | and if you have e.g. a 3D vector or a fixed point number or something, then it's useful to overload + for addition because it lets you write much more understandable code than with explicit method calls |
| 13:55 | <Lachy> | takkaria, at least in C++, you don't have dynamically typed variables, so you know what + is going to be just by looking at the code |
| 13:55 | <takkaria> | Lachy: well, you don't, because as you note, it can do anything |
| 13:55 | <takkaria> | you have to then go look up the class in question |
| 13:55 | <Philip`> | (and then it's useful for generic programming, e.g. you can write a templated 'sum' function which works for 3D vectors just as well as it works for ints) |
| 13:55 | <takkaria> | and then possibly its superclass(es) |
| 13:56 | <Lachy> | takkaria, as long as you know the varible type and what that type does with it. |
| 13:56 | <Philip`> | takkaria: How is that any different to an explicit method call, which can do anything? |
| 13:56 | <takkaria> | Philip`: because '+' and '-' have pretty deeply embedded meanings, and some people do horrific things with operator overloading |
| 13:57 | <takkaria> | for stuff like vectors and strings, admittedly, it works OK |
| 13:57 | <takkaria> | but they should be language features anyway :) |
| 13:57 | <Philip`> | If people do horrific things, the problem is that people are doing horrific things, the problem isn't simply operator overloading |
| 13:57 | <Philip`> | and so the solution is to tell people not to do horrific things, and hit them with sharp sticks when they do |
| 13:57 | <takkaria> | yeah, but if you give people a feature which is easily misused, then you're partially to blame and you should have designed things better |
| 13:57 | <Philip`> | What if you don't like the standard string class and want to create your own that uses UTF-8 internally or something? |
| 13:58 | <Philip`> | Would it have to be a second-class citizen with string1.concat(string2) while only officially blessed standard strings can use +? |
| 13:59 | <takkaria> | I don't have all the answers, I just know that it's really easy for people to misuse operator overloading and I'd rather it were avoided |
| 14:00 | <takkaria> | especially when you have to search up chains of inheritance in a large codebase |
| 14:03 | <Philip`> | The replacement for operator overloading is explicit method calls, and then you have to identically search up chains of inheritance, so why is that any different? |
| 14:03 | <Philip`> | (You're just searching up the chains for 'add' rather than for 'operator+') |
| 14:04 | <takkaria> | you may have backed me into a corner here |
| 14:05 | <Philip`> | Because you're wrong? ;-) |
| 14:05 | <takkaria> | I think I just don't have particularly good reasons for disliking them |
| 14:05 | <takkaria> | except that I've been exposed to some bad overloading |
| 14:05 | <Philip`> | So it's an irrational aesthetic dislike? :-) |
| 14:06 | <takkaria> | apparently so |
| 14:07 | <workmad3> | the problem with overloading isn't really in the operator overloading part, more in the fact that people think they have to use it |
| 14:07 | <Philip`> | Aesthetics seems to be a pretty low priority in the design of C++ |
| 14:08 | <workmad3> | people are able to overload all the operators, so they go looking for things to jam into each and every one in order to 'use them up' as it were |
| 14:09 | <Lachy> | workmad3, really? Why? |
| 14:09 | <Philip`> | http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/quick_start.html |
| 14:09 | <workmad3> | and that leads to programmers with that mentality to write bad overloads |
| 14:09 | <Philip`> | r = real_p >> *(ch_p(',') >> real_p); |
| 14:09 | <Lachy> | do they think it makes their code more robust to be able to handle all operators or something? |
| 14:09 | <Philip`> | (A parser for a comma-separated list of reals) |
| 14:09 | <workmad3> | Lachy, if I knew why people abused operator overloading, I probably wouldn't be sat here :P |
| 14:10 | <Philip`> | (It's kind of clever, but also insane and stupid) |
| 14:10 | <workmad3> | Lachy, that, or they are looking for ways to reduce their typing, or they want it to be a 'cool' class that lets them do all of these things |
| 14:10 | <takkaria> | actually, the C++y 'cout << "text here"' thing really annoys me |
| 14:10 | <takkaria> | like, those operators are for bitshifting, not for printing text, don't screw with the semantics like that |
| 14:11 | <takkaria> | I'm pretty sure they only did it that way to say "look, we have operator overloading!" |
| 14:11 | <workmad3> | I dislike them for a different reason... it's almost impossible to do decent localisation with C++ streams |
| 14:12 | <Lachy> | next time I write a program in C++, I'm going to overload some random operators just for the fun of it |
| 14:12 | <workmad3> | heh :) |
| 14:13 | <erlehmann> | Lachy, or use the preprocessor to make TRUE to FALSE and vice versa -- maintainer fun :D |
| 14:13 | <workmad3> | that said, my point on that front isn't that operator overloads are bad, it's that there are a lot of bad programmers out there that will misuse them... but the same is true of any feature |
| 14:13 | <Philip`> | (std::cout << "text" is particularly confusing when you learn that the operator<< function is in the std namespace, and the only way the compiler can find the function is through argument-dependent lookup, i.e. it searches in the std namespace because the first argument is in std) |
| 14:16 | <workmad3> | there is one nice thing about input and output streams using overloaded operators in C++ though (and this is more due to their operator overloading mechanics)... you can easily extend the input and output streams to use your custom classes and it'll fit in seamlessly with the existing syntax |
| 14:16 | <takkaria> | I think the other reason the use of << for printing irks me is that a barrel shift operator is normally stateless, e.g. (a << b) is just an expression and doesn't modify a in the process |
| 14:17 | <Philip`> | C++ using bit-shift operators from stream IO isn't much weirder than Python using the modulo operator from string interpolation |
| 14:17 | <Philip`> | s/from/for/ |
| 14:17 | <Philip`> | (twice) |
| 14:17 | <workmad3> | ruby uses << for appending to arrays :) |
| 14:17 | <takkaria> | yeah, that's weird too |
| 14:17 | <workmad3> | that took me a few times to parse correctly |
| 14:19 | <workmad3> | still, hating a language feature because some people have misused it is irrational |
| 14:19 | <workmad3> | equivalent to hating hammers because they have been used to hurt people |
| 14:20 | <takkaria> | I have seen many hammers and I have never seen someone hurting someone else |
| 14:20 | <takkaria> | I have seen not that much C++ and I have seen overloading misused |
| 14:20 | <workmad3> | I've seen a fair chunk of C++ and not seen too much overloading misuse |
| 14:21 | <workmad3> | and I've hurt myself with a hammer before, and heard of people hurting others with them |
| 14:23 | <workmad3> | I've not heard anyone suggesting that because they can be used to hurt people though, that instead we should get rid of hammers and replace them with soft foam mallets instead |
| 14:23 | <workmad3> | (and no, I don't have a match in programming terms for 'soft foam mallets' in this now stretched metaphor) |
| 14:24 | <zcorpan> | hmm, removing <source> elements is interesting |
| 14:24 | <Philip`> | Knives can be used to hurt people, so somebody designed a knife that can't stab people and is suggesting that people use it |
| 14:24 | <workmad3> | ah yeah, I saw that |
| 14:25 | <workmad3> | and also saw straight away that it could still probably stab people, and definitely be used to cut (otherwise it wouldn't be any good as a knife after all :)) |
| 14:25 | <Philip`> | but in that case the knife is still useful for its intended purpose (food production) |
| 14:25 | <workmad3> | it may need a bit more forcing for the stabbing though |
| 14:25 | <Philip`> | If there was something equivalent to operator overloading that avoided the bad uses without impacting on the good uses, that would be good, but I haven't seen any suggestions |
| 14:27 | <Philip`> | (Well, I suppose operator overloading plus code review by a sane person would be a solution) |
| 14:27 | <TabAtkins> | Mornin'. |
| 14:28 | <workmad3> | sane people program now? when did that happen? :) |
| 14:28 | <Philip`> | workmad3: They could have retired from programming and regained their sanity, to a sufficient extent that they can review other people's code |
| 15:45 | <TabAtkins> | Is it defined anywhere what happens to content in <details> that isn't contained in a <dt> or <dd>? |
| 15:47 | <jgraham_> | TabAtkins: Define "happens" |
| 15:47 | <jgraham_> | It ends up in the DOM. The rendering section defines how it is rendered |
| 15:48 | <jgraham_> | (the rendering section might have a suboptimal definition of course, I don't know what it says) |
| 15:52 | <TabAtkins> | Ah, got it. For some reason I never go from "how is something parsed/rendered" to "I should look in the 'HTML Syntax' section". |
| 15:52 | <TabAtkins> | Everything but the first <dt> is considered to be the details. |
| 16:03 | zcorpan | notes that there are unresolved spec bugs regarding the rendering of details |
| 16:08 | <jgraham_> | I really dislike the idea of using h1 for <details> or <figure>. In particular I would expect it to interact poorly with legacy AT |
| 16:11 | <krijnh> | In <figure> it wouldn't make much sense either: <figure><img><h1>Foo</h1></figure> |
| 16:13 | <jgraham_> | Actually the biggest problem I forsee with <dt> and <dd> is that it is way to easy to get them confused |
| 16:14 | <jgraham_> | They should have been called <name> and <value> or something |
| 16:14 | <Lachy> | too late for that, unfortunately |
| 16:14 | <jgraham_> | The confusion is especially bad for <figure> because it is pretty hard to spot |
| 16:14 | <jgraham_> | Lachy: I know :( |
| 16:15 | <erlehmann> | when no access control header is sent for videos, is thet akin to access for "*" ? |
| 16:15 | <erlehmann> | jgraham_, who uses that? is <legend> unexpectedly dead? |
| 16:15 | <Lachy> | I'm not a huge fan of reusing dt and dd for figure |
| 16:15 | <Lachy> | though it works well for details |
| 16:15 | <jgraham_> | erlehmann: <legend> is just for fieldsets again |
| 16:15 | <erlehmann> | OH NOEZ |
| 16:17 | <jgraham_> | TabAtkins: Reusing <h1> would also be bad in cases where the user fell back to the UA stylesheet in an existing browser |
| 16:18 | <TabAtkins> | jgraham_ No worse than what happens if you use <h1> for all headings, though. |
| 16:18 | <erlehmann> | i hate it when they change the spec. |
| 16:18 | <erlehmann> | coding to moving targets ;_; |
| 16:18 | <erlehmann> | jgraham_, using <h1> wouldn't that confuse older UAs particularly concerning accessability ? |
| 16:18 | <erlehmann> | everything would be HUGE |
| 16:18 | <jgraham_> | TabAtkins: Much worse. A figure caption could be several paragraphs of text |
| 16:18 | <erlehmann> | why was legend not good enough ? i had no major parsing or styling problems with it in webkit, presto, gecko … |
| 16:18 | <Lachy> | erlehmann, that is the inevitably fate of early adopters |
| 16:18 | <jgraham_> | In fact aren't there parsing issues with <h1> |
| 16:18 | <Lachy> | *inevitable |
| 16:18 | <TabAtkins> | Are there? |
| 16:19 | <erlehmann> | Lachy, my code ist frozen till 2022, then. |
| 16:19 | <Lachy> | :-) |
| 16:19 | <erlehmann> | now can anyone tell me whats so bad about legend ? |
| 16:19 | <erlehmann> | was it on the list? |
| 16:20 | <Lachy> | on an unrelated issue, I was thinking about the styling of headings today and the idea that's been floating around of introducing a :heading() pseudo class |
| 16:20 | <erlehmann> | so :heading(2) would be for 2-level headings? |
| 16:21 | <Lachy> | it seems that hgroup and the issue of subheadings make the issue a little more complicated |
| 16:21 | <Lachy> | erlehmann, in principle, yes |
| 16:21 | <erlehmann> | either its too late for that or CSSWG has something like this already, let me check. |
| 16:22 | <TabAtkins> | I know that :heading() (and :section()?) has been discussed before, quite some time ago. |
| 16:22 | <Lachy> | e.g. should :heading(2) match the h2 in <hgroup><h1>Top Level Heading</h1><h2>Subheading</h2></hgroup>? |
| 16:22 | <TabAtkins> | I think it's pretty necessary. |
| 16:22 | <TabAtkins> | Lachy: No, it should match the <hgroup> itself, if it represents a second-level heading. |
| 16:23 | <jgraham_> | TabAtkins: In practice no one uses <h1> in blockquote (I expect) |
| 16:23 | <Lachy> | TabAtkins, assume there's a <body> immediately before that example of mine, so it's the page's top level heading |
| 16:23 | <jgraham_> | That bit of the spec is basically theoretical purity |
| 16:24 | <TabAtkins> | Lachy: Then I dont' think it should match. The <hgroup> would match :heading(1), but its child headings won't match *any* :heading(n). |
| 16:24 | <Lachy> | TabAtkins, also, I would have intuitively expected the :heading() pseudo to only match the h1 (if it were a 2nd level heading) |
| 16:25 | <erlehmann> | put it on the list, already \o/ |
| 16:25 | <TabAtkins> | That's possibly, too, I guess - just having it match the identifying heading of the hgroup. |
| 16:25 | <Lachy> | as in <body>...<section><h1>2nd Level Heading</h1>...</section> OR this <body>...<section><hgroup><h1>2nd Level Heading</h1><h2>...</h2></hgroup>...</section> |
| 16:25 | <TabAtkins> | jgraham_, I agree that it's probably not common. |
| 16:25 | <krijnh> | Did the list receive mail today? |
| 16:25 | <jgraham_> | krijnh: Yes |
| 16:25 | <krijnh> | Then my mail is broken :( |
| 16:25 | <TabAtkins> | krijnh - yes? |
| 16:26 | <hsivonen> | Lachy: shouldn't the pseudo match other elements based on their level in the outline, too |
| 16:26 | <jgraham_> | krijnh: Then you have a whole run of thrilling and not-at-all-inflammatory messages to look forward to! |
| 16:26 | <TabAtkins> | Lachy: That seems probably useful. I'm not certain, but I wouldn't disagree with it. |
| 16:26 | <krijnh> | jgraham_: I think they didn't arrive |
| 16:26 | <Lachy> | also i checked jQuery's docs earlier, and that uses a custom :header for matching h1 - h6, so there shouldn't be any issue with calling it :heading() as I once suspected |
| 16:26 | <krijnh> | What should I do with all this extra time I have now! |
| 16:27 | <Lachy> | hsivonen, yes, it should match any of the h1 to h6 elements, based on what heading level they represent |
| 16:27 | <Lachy> | I'm just figuring out how hgroup and subheadings would be affected |
| 16:27 | <hsivonen> | Lachy: I meant matching p:outline-level(3) |
| 16:27 | <Lachy> | what's the use case for that? |
| 16:28 | <hsivonen> | Lachy: setting the font size or bg color depending on outline depth |
| 16:28 | <jgraham_> | (or indent) |
| 16:28 | <Lachy> | the use case for headings is replacing what was formerly possible in HTML4 simply by using the numbered heading elements. |
| 16:28 | <hsivonen> | jgraham_: that, too |
| 16:28 | <TabAtkins> | I sorta prefer ::section(n). It's a new pseudoelement, but it doesn't cross element boundaries and has an intuitiviely obvious wrapping level. |
| 16:29 | <TabAtkins> | That way you can do borders, margins, etc. even if using implicit sectioning. |
| 16:29 | <Lachy> | TabAtkins, interesting idea |
| 16:29 | <hsivonen> | we should have <figure><bikeshed></figure> |
| 16:30 | <takkaria> | <figure><span role="semantic-meaning"></span></figure> |
| 16:30 | <TabAtkins> | hsivonen: Put it to a vote. I'm for it. But I require <bikeshed color="#f00"> |
| 16:30 | <hsivonen> | TabAtkins: I want color=papayawhip |
| 16:30 | <erlehmann> | I WANT MAH LEGEND BACK |
| 16:30 | <erlehmann> | <div class="figure presentation"><span role="semantic-meaning"></span></div> |
| 16:30 | <erlehmann> | i want a pony ! |
| 16:31 | <erlehmann> | color=ponypink ! |
| 16:32 | <Lachy> | TabAtkins, with the ::section() pseudo-element, that makes styling section elements by their nesting level a little confusing, since if you do section::section(n), you end up styling the pseudo instead of the section element itself |
| 16:32 | <TabAtkins> | Lachy: Heh, I was just in the middle of typing exactly that. |
| 16:33 | <Lachy> | and that's a little problematic if you want to set default styles for section, and then override them based on the level |
| 16:33 | <Lachy> | and I'd rather not have :section() pseudo-class and a ::section pseudo-element to cover both cases |
| 16:33 | <TabAtkins> | Lachy: One possibility is making ::section(all) work, or similar. That way if you were using ::section at all, you'd *always* use it. |
| 16:34 | <TabAtkins> | And you wouldn't have to distinguish between explicit <article>/<section>/etc |
| 16:34 | <TabAtkins> | Of course, this would absolutely require the relaxation of the "only one pseudoelement, and only at the end" requirement. |
| 16:35 | <Lachy> | why would it? |
| 16:35 | <TabAtkins> | Because it seems silly that you can do section::before but not ::section(1)::before. |
| 16:35 | <TabAtkins> | Or ::section > p |
| 16:36 | <krijnh> | Silly putty? |
| 16:36 | <Lachy> | also, that won't work cause you want to style elements within that pseudo element, you'd have weird stuff like this: ::section(3) p { color: blue; } |
| 16:36 | <TabAtkins> | ::silly > putty |
| 16:36 | <TabAtkins> | Is that weird? I don't think so. |
| 16:36 | <Lachy> | I don't think pseudo elements normally have descendants |
| 16:37 | <TabAtkins> | Not normally. |
| 16:37 | <TabAtkins> | But why should that stop us? |
| 16:37 | <Lachy> | how does it work with the ::outside pseudo? |
| 16:37 | <TabAtkins> | (Also, I think that's mostly an accident of history.) |
| 16:37 | <TabAtkins> | Are you asking what ::section(3)::outside would do? |
| 16:38 | <Lachy> | no, what does this do: ::outside p { ... } |
| 16:38 | <TabAtkins> | Oh, I see. It would work exactly as you'd think. ::outside is a wrapper element, and it has the same descendants as its superior parent. |
| 16:38 | <Lachy> | I forget with CSS draft outside is defined in |
| 16:38 | <TabAtkins> | Generated Content. |
| 16:39 | <Lachy> | makes sense |
| 16:39 | <TabAtkins> | Hixie's the editor. >_< |
| 16:39 | <Lachy> | he was. Not any more. It's just that no-one has touched it since |
| 16:39 | <takkaria> | I wonder if CSS3 will ever be Turing-complete |
| 16:39 | <takkaria> | or rather, just CSS |
| 16:40 | <Lachy> | takkaria, then what happens with div::outside div |
| 16:40 | <Lachy> | I mean, div::outside>div |
| 16:40 | <TabAtkins> | That's a very good question, and I think both immediate answers are reasonable. |
| 16:40 | <Lachy> | s/takkaria/TabAtkins/ |
| 16:41 | <TabAtkins> | That is, it would be reasonable for ::outside to have its superior parent as a child, but it would also be reasonable to just say that it doesn't, and that its descendants are identical to those of its superior parent. |
| 16:41 | <Lachy> | TabAtkins, takkaria, one of you has to change your name. You're messing with my autocomplete! :-) |
| 16:41 | <TabAtkins> | Just type three letters! |
| 16:41 | <TabAtkins> | And I could go back to Xanthir, but then nobody knows who I am. |
| 16:42 | <Lachy> | no, it's fine. I'll deal with it |
| 16:42 | <TabAtkins> | Using the latter would probably work better in conjuction with a theoretical ::inside as well - all three (base element, ::outside, and ::inside) would have the same set of descendants. |
| 16:43 | <takkaria> | public-html was getting reasonably technical before this dt thread came along |
| 16:44 | <TabAtkins> | It's too easy to blame Shelley, so I'm going to blame Lief for it, takkaria. |
| 16:44 | <hsivonen> | who is behind this: http://www.o3mobi.com/ ? |
| 16:44 | <Lachy> | takkaria, then it's good the dt thread started then. We can't mess with the status quo, and have public-html become productive all of a sudden. That would create all sorts of confusion. |
| 16:45 | <takkaria> | "oh no, a sudden outbreak of productivity! quick, build a bikeshed over it!" |
| 16:45 | <Lachy> | what colour?! |
| 16:47 | <takkaria> | "we can't reuse an old colour, we need a new colour, one which no-one has ever even imagined before" |
| 16:48 | <TabAtkins> | breenwhip |
| 16:49 | <TabAtkins> | So hey, let's talk about <h1> some more. There was something about figure>h1 containing paragraphs of content, and this being a problem? |
| 16:49 | <TabAtkins> | Presumably a styling problem, having paragraphs of 2em-tall text. |
| 16:49 | <TabAtkins> | Also maybe a parsing issue? |
| 16:50 | <takkaria> | don't think there are parsing isues with <h1> |
| 16:50 | <Lachy> | takkaria, we should pick a colour outside of the visible light spectrum so that we can be sure it hasn't been used before |
| 16:51 | <TabAtkins> | jgraham_ mentioned a possible parsing issue, but didn't go into details. |
| 16:54 | <Lachy> | I'm not sure what parsing issue he was referring to either. I don't know of any that would have any relevance within figure |
| 16:55 | <TabAtkins> | All right, I will assume drugs were involved until further notice. |
| 16:55 | <da3d> | Lachy: Octarine :) |
| 16:59 | <TabAtkins> | So, is the only issue with <h1> in <figure> a display issue? (One that can be trivially fixed in an author's CSS.) |
| 16:59 | <hsivonen> | http://whois.net/whois/o3mobi.com |
| 16:59 | <hsivonen> | looks like someone wants to publish interesting software but stay secret about who they are |
| 17:21 | <boblet_> | TabAtkins: was the parsing issue from jgraham_ you were referring to the concern about <figure><h1> in legacy AT? |
| 17:21 | <TabAtkins> | I dunno. He didn't give details, so maybe? |
| 17:22 | <boblet_> | “jgraham_: I really dislike the idea of using h1 for <details> or <figure>. In particular I would expect it to interact poorly with legacy AT” |
| 17:22 | <boblet_> | just in case that’s more info than you already had |
| 17:22 | <boblet_> | (a couple of hours ago) |
| 17:23 | <zcorpan> | TabAtkins: what if you want <h1> to be the figure content? |
| 17:24 | <zcorpan> | <dt> and <legend> cannot be the figure content because they are only allowed in some special places |
| 17:24 | <boblet_> | (ah, you were in that conversation I see—ignore) |
| 17:25 | <TabAtkins> | zcorpan: Either make the <h1> that's supposed to label the figure come first, or put the <h1> that's supposed to be in the figure content in a wrapper of some sort - only the first h1 *child* of figure would be considered. |
| 17:27 | <MikeSmith> | boblet_: thanks for the Google ウェーブ pointer |
| 17:28 | <boblet_> | MikeSmith: np—one of my Twitter friends mentioned she’d be going to a Wave talk at Kyoto GUG so it was easy to ask |
| 17:28 | <boblet_> | looks like the Tokyo one was earlier |
| 17:32 | <gsnedders> | Anyone who speaks French around? |
| 17:32 | <Philip`> | I can paste text into Google Translate |
| 17:32 | <Philip`> | Does that count? |
| 17:32 | <boblet_> | Philip` is armed and dangerous |
| 17:32 | <gsnedders> | Philip`: no |
| 17:34 | <krijnh> | gsnedders: pourquoi? |
| 17:34 | <gsnedders> | krijnh: "les photos du bal de moi" is wrong, is it not? How would I phrase that? |
| 17:34 | <MikeSmith> | gsnedders: plh speaks French, plus speaks English with a French accent |
| 17:35 | <MikeSmith> | I think Hixie speaks French too |
| 17:35 | <gsnedders> | Yeah, Hixie speaks the (Swiss) French of a 10 year old kid. |
| 17:35 | <hober> | Hixie: I guess you were right re: s/en-US-x-Hixie/en-US/ in that blog post; an excerpt from it on ajaxian.com includes the full, joke lang="" value |
| 17:35 | <MikeSmith> | and karlcow does too a little |
| 17:35 | <gsnedders> | But he's asleep right now, so he isn't very useful. |
| 17:35 | <Rik|work> | gsnedders: I'm French |
| 17:35 | gavin | speaks french |
| 17:35 | <gsnedders> | Rik|work: See above |
| 17:36 | <gavin> | "Des photos de moi au bal"? |
| 17:36 | <gavin> | "Des photos de mon bal"? |
| 17:36 | <Rik|work> | gsnedders: do you speak about pictures of you at a bal or pictures of your bal |
| 17:36 | <gsnedders> | Rik|work: Of me at a ball |
| 17:36 | <gavin> | my 1st option then |
| 17:36 | <gavin> | s/Des/Les/ if desired |
| 17:37 | <Rik|work> | gsnedders: "Des photos de moi au bal", as gavin said |
| 17:37 | <gsnedders> | Ah, so you'd use à, etc. for what a photo is of? |
| 17:37 | <Philip`> | Hint for writing specs: Put the most controversial stuff at the end, so anyone reviewing the document is too tired by that point to comment on it |
| 17:37 | <gsnedders> | (Or where it comes from, rather) |
| 17:38 | <gavin> | equivalent to "Photos of me _at a_ ball" |
| 17:38 | <gsnedders> | Yeah, right |
| 17:38 | <gsnedders> | You wouldn't say photos of me of the ball in English either… |
| 17:39 | <gsnedders> | Pah. I just need to think more :) |
| 17:39 | <TabAtkins> | Though it would be appropriate to say "photos of me from the ball", which would also be "a" in Spanish at least. |
| 17:39 | <TabAtkins> | Gah, I mean "de". |
| 17:40 | <gavin> | "Mes photos du bal" is "My photos from|of the bal" |
| 17:40 | <boblet_> | hober: nice article btw :) |
| 17:40 | <gsnedders> | gavin: Yeah, right, I know fine |
| 17:40 | <gsnedders> | gavin: I just always fail to think of how to say stuff in French, though I'm fine when given French to read. |
| 17:41 | <gavin> | yeah I have that problem too actually... despite having done K-12 entirely in french, I hardly ever get to speak/read it in day-to-day life nowadays |
| 17:42 | <gavin> | so its easy to lose familiarity with phrasing/expressions/etc. |
| 17:43 | <gsnedders> | All of the French relatives I speak to semi-regularly are bilingual, and as my French has fallen out of practice I've stopped speaking French to them so much (as doing so is harder), hence making my French ever more out of practice |
| 17:54 | <tantek> | gsnedders - if you want practice French, especially in speaking about the web, check out #openweb |
| 17:54 | <Rik|work> | don't go there, it's full of strange people |
| 17:55 | <Rik|work> | gsnedders: if you wanna practice french, come to http://www.paris-web.fr/2009/ |
| 18:00 | <MikeSmith> | .me sees bruce lawson tweet about object and tries to remember why @classid on object is not defined as a conformant attribute in the spec |
| 18:01 | <hsivonen> | MikeSmith: it's product-specific |
| 18:02 | <hsivonen> | (to IE) |
| 18:02 | <MikeSmith> | ah |
| 18:02 | <hsivonen> | MikeSmith: it's also redundant with the mime type-based dispatch |
| 18:02 | MikeSmith | remembers some list discussions now |
| 18:03 | <MikeSmith> | hsivonen: thanks |
| 18:03 | <MikeSmith> | bruce should just get on IRC |
| 18:04 | MikeSmith | will be glad when this whole microblogging fad is over and people rediscover irc |
| 18:04 | <MikeSmith> | Google Wave is basically just IRC, but with images and what-not |
| 18:05 | <Philip`> | Google Wave is to IRC as HTML email is to plain text email |
| 18:05 | <MikeSmith> | heh |
| 18:05 | <MikeSmith> | IRC is just like CB radio, except with text instead of actual talking |
| 18:06 | <erlehmann> | Google Wave is to IRC what Battlestar Galactica is to Voyager |
| 18:06 | <othermaciej> | IRC is such a crufty and half-assed protocol |
| 18:06 | <Rik|work> | MikeSmith: there's a backlog with IRC, not with CB |
| 18:06 | <Philip`> | I remember the PowWow chat program (long long ago, before ICQ) where you could see the characters people were typing in real time, and you could change your font and background colour |
| 18:06 | <TabAtkins> | The nice thing about tweets is that they are relatively permanent and searchable, unlike your average IRC room. |
| 18:06 | <othermaciej> | it's a wonder that it hasn't been either replaced or properly specified by RFC |
| 18:06 | <Philip`> | so naturally I had 24pt magenta Comic Sans on a yellow background |
| 18:06 | <erlehmann> | Rik|work, there is a backlog on entry with Jabber MUC |
| 18:06 | <Philip`> | It was horrid |
| 18:07 | <MikeSmith> | LL Cool J once said that IRC rocks the bells |
| 18:07 | <erlehmann> | Philip`, iNtErEsTiNg :D |
| 18:07 | <MikeSmith> | I think the Too Live Crew said it too |
| 18:08 | <Philip`> | erlehmann: Watch out, I think you may have a small animal jumping up and down on your shift key |
| 18:08 | <erlehmann> | yurr |
| 18:08 | <TabAtkins> | I think we need a text-transform:alternating-caps value. |
| 18:09 | <erlehmann> | it will be integrated in CSS3 text modes, together with text-transform:rot13 and text-transform:leet |
| 18:09 | <TabAtkins> | I am satisfied with this progress. |
| 18:09 | <erlehmann> | CSSquirrel comic about that proposal in three, two, one … |
| 18:09 | <Rik|work> | we need text-transform: banner; and text-transform: figlet too |
| 18:10 | <Philip`> | othermaciej: You mean like http://tools.ietf.org/html/rfc2810 (plus the subsequent three)? |
| 18:10 | <Philip`> | or are those just not "proper"? |
| 18:10 | <othermaciej> | Philip`: my understanding is that clients and servers all deviate from those RFCs in various ways (but I could be misinformed) |
| 18:11 | <Philip`> | othermaciej: That's true of all specifications, so IRC doesn't seem particularly special in that way |
| 18:11 | <Philip`> | Maybe IRC has many more deviations than most protocols, though |
| 18:12 | <takkaria> | the IRC RFCs are good enough to write a client with, generally |
| 18:13 | <othermaciej> | Philip`: fair enough |
| 18:13 | Philip` | wrote a text-based FPS game which provided an IRC server interface, and it probably totally violated all the RFCs but it actually worked quite nicely with mIRC |
| 18:20 | <tantek> | TabAtkins, erlehmann, you should propose those additional text-transform features for CSS4.1, as I did with "text-transform:continental" here: http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html |
| 18:24 | <TabAtkins> | tantek: I see that text-transform:l33t was already suggested in that thread. |
| 18:25 | <tantek> | TabAtkins, indeed, although I would suggest text-transform:1337 instead |
| 18:57 | <TabAtkins> | tantek, you planning on writing up that <pre separator> proposal anytime soon? |
| 19:09 | <Lachy> | TabAtkins, what's the <pre separator> proposal? |
| 19:09 | <tantek> | TabAtkins - yes I have a .txt file on it |
| 19:10 | <TabAtkins> | Lachy: A proposal to make allow csv data to be treated like a table. Put it in <pre>, specify what the separator is (tab, comma, etc), and bam. |
| 19:10 | <Lachy> | interesting |
| 19:10 | <TabAtkins> | I've got a js parser built for it that just swaps the <pre> out for an equivalent <table>. |
| 19:11 | <TabAtkins> | tantek mentioned it offhand one day, I thought it was interesting and threw together a parser in about 20 minutes. Then I spent some time to make a *good* parser that will actually work on real content. |
| 19:11 | <TabAtkins> | http://www.xanthir.com/etc/csv.htmlhttp://www.xanthir.com/etc/csv.html |
| 19:11 | <TabAtkins> | http://www.xanthir.com/etc/csv.html rather |
| 19:13 | <Lachy> | how would that work with styling though? Presumably, a browser implementation would leave the <pre> in the DOM, rather than replacing it, but render it as a table |
| 19:13 | <Lachy> | seems like something that could, in theory, be done with an XBL binding |
| 19:13 | <tantek> | Lachy - you could use the table pseudo-elements from CSS |
| 19:13 | <tantek> | even easier than XBL |
| 19:13 | <Lachy> | does CSS have table pseudo-elements now? |
| 19:13 | <annevk2> | there are no table psuedo-elements |
| 19:14 | <TabAtkins> | Lachy: Dunno, unfortunately. You'd probably have to go with something like XBL somehow. |
| 19:14 | <Lachy> | I suspect annevk2 is right. I've not seen them before |
| 19:14 | <annevk2> | and implementing them for this seems a little excessive for something that can be done through scripting |
| 19:15 | <Lachy> | I've heard proposals for table related pseudo-classes though, but they wouldn't work here |
| 19:15 | <TabAtkins> | Yeah, those discussion were just for :col() and :nth-col() |
| 19:16 | <TabAtkins> | You really would need either pseudoelements, or a CSS shadow tree. |
| 19:16 | <annevk2> | your feature proposal is not going to make it then :) |
| 19:17 | <TabAtkins> | Noes! |
| 19:17 | TabAtkins | cries. |
| 19:17 | <dbaron> | I wanted :col() and :nth-col() to be pseudo-classes, not pseudo-elements. |
| 19:17 | <TabAtkins> | dbaron: Yeah, we're not trying to abuse those into working here. ^_^ |
| 19:17 | <gsnedders> | tantek: I have almost no technical French, so that would be hard. |
| 19:18 | <gsnedders> | Rik|work: If you can get my employer to pay for me to go :P |
| 19:18 | <Rik`> | gsnedders: which is ? |
| 19:18 | <gsnedders> | Rik`: Opera |
| 19:18 | <Rik`> | oh, Molly and Chaals are already coming |
| 19:19 | <TabAtkins> | The big problem, I think, even bigger than styling, is just how it's supposed to be exposed in the dom. Part of the point of <pre separator> is that it is supposed to magically *act* like a <table>. |
| 19:19 | <gsnedders> | Rik`: Don't you know half this channel works for Opera? :P |
| 19:19 | <TabAtkins> | I suggest we just swap the <pre> out in the dom for a <table>. That solves everything. ^_^ |
| 19:20 | <annevk2> | you seriously think all this complexity is worth it over a simple online cvs to HTML <table> converter? |
| 19:20 | <annevk2> | because if you do you'd be wrong |
| 19:20 | <TabAtkins> | I think it was a fun project to work on. Tantek's the one with the vision. |
| 19:20 | <annevk2> | s/cvs/csv/ |
| 19:20 | <tantek> | annevk2 - what complexity? |
| 19:20 | <Rik`> | gsnedders: you should talk with Chaals, he's really speaking a good French |
| 19:21 | <tantek> | and if an online cvs to HTML <table> converter is so simple, where are they? show some URLs - or else it's not simple. |
| 19:21 | <gsnedders> | Rik`: I scarcely have the opportunity to speak to him. |
| 19:22 | <Rik`> | so do I, lots of unanswered mails :( |
| 19:22 | <gsnedders> | Rik`: I could far more easily just talk to one of my French relatives :) |
| 19:23 | <tantek> | TabAtkins - the DOM problem is fairly straightforward, on <pre>s with separator, they get the <table> DOM interface as well |
| 19:23 | <TabAtkins> | tantek: You mean other than my converter? ^_^ |
| 19:25 | <tantek> | TabAtkins - right - your converter does it inline in a document, expressly to demonstrate the utility of <pre separator> - whereas annevk2 is implying a .cvs (like an entire file) to <table> converter |
| 19:25 | <TabAtkins> | I found at least one of those, actually. |
| 19:26 | <annevk42> | tantek, styling, DOM, etc. |
| 19:26 | <tantek> | annevk42, the DOM is a solved problem. |
| 19:26 | <annevk42> | tantek, there's no need to have a separate syntax for something that's essentially a table |
| 19:26 | <tantek> | give it a .table property that gives a <table> interface, done |
| 19:27 | <annevk42> | euhm, no |
| 19:27 | <tantek> | annevk42 - the utility is the rapid/easy re-use of all the opengov etc. data out there |
| 19:27 | <annevk42> | but I'm not going to waste my time on this -- have fun :) |
| 19:27 | <tantek> | your phrase "essentially a table" completely misses the point of the current difficulties that the open gov and science communities have today with datasets |
| 19:28 | <TabAtkins> | http://plugins.jquery.com/project/csv2table |
| 19:29 | <annevk42> | tantek, is the difficulty exporting it to HTML? |
| 19:30 | <tantek> | annevk42 yes that's a big part of it, and then having libraries to interact with <table> as they do with csv today. |
| 19:30 | <tantek> | also, when you have huge datasets, the tagjunk from explicit <table> markup tends to bloat them (like double the size etc.) |
| 19:31 | <tantek> | slows down processing efficiency etc. |
| 19:31 | <tantek> | why would you convert your csv to explicit <table> markup if that meant processing your data would take 2 days instead of 1? |
| 19:32 | <tantek> | etc. |
| 19:32 | <annevk42> | why would you convert it before processing? |
| 19:42 | Guest31664 | should probably ask here before he starts filling up Hixie's inbox with old tokenisation issues. |
| 19:44 | <and> | Sorry, wrong nickname. |
| 19:45 | <and> | 1) At end of file, unclosed comments and DOCTYPEs are output, but not unclosed start and end tags. Is there a reason not to output whatever is unclosed at EOF? |
| 19:46 | <and> | 2) Is it really necessary to handle slashes inside tags as whitespace now when it is handled specially at the end of void elements? |
| 19:47 | <and> | 3) --!> and -- > (with a space) do not close short comments, i.e., those that contain only two or three hyphens. |
| 19:48 | <and> | 4) Would it make sense to extend the concept of non-ambiguous ampersand? It is only truly ambiguous before A-Z, a-z and # anyway. |
| 19:49 | <annevk42> | 2) pretty sure the answer is yes |
| 19:49 | <takkaria> | 1) was changed for security reaosns from outputting those tags to not outputting them |
| 19:50 | <annevk42> | 3) might be a bug, dunno |
| 19:50 | <and> | In case the last part of the file is missing? |
| 19:52 | <takkaria> | yeah, something like that |
| 19:52 | <jgraham_> | and: In case an attacker manages to cause an EOF I think |
| 19:54 | <jgraham_> | and: I think 3) is because Hixie didn't want those to close comments at all but it is needed for web-compat |
| 19:54 | <jgraham_> | so he made it happen in as few places as possible |
| 19:54 | <jgraham_> | (but it might be a bug) |
| 19:55 | <and> | I do not quite see how the current behaviour helps, though. Presumably, it would be just as easy to insert EOF before the tag as in the middle? |
| 19:58 | <annevk42> | prevents executing scripts |
| 19:59 | <and> | If there is an onload on the element in question? (I am probably missing something obvious.) |
| 20:00 | <and> | s/element/tag/ |
| 20:05 | <annevk42> | if it's a <script> tag |
| 20:05 | <annevk42> | i forgot the exploit details to be honest |
| 20:07 | <and> | I guess a <script> tag with an unfinished src attribute might be problematic. |
| 20:08 | <and> | Thanks everyone! |
| 20:09 | <and> | (though it does not seem particularly easy to exploit) |
| 20:16 | <and> | annevk2: I did finish testing encoding labels in IE last week, by the way. In summary: The "gb2312-80" label does not work. Almost all the (???) encodings seem problematic, most of them perhaps not supported. I have no idea what "x-europa" refers to. UTF-7 and four somewhat obscure Taiwanese encodings have not been tested at all. |
| 20:18 | <and> | annevk2: The last sentence on the wiki seems wrong (... make such an effort probable). |
| 20:23 | Philip` | sees that and is in cam.ac.uk |
| 20:23 | <Philip`> | It's a hotbed of tokeniser activity :-o |
| 20:24 | <TabAtkins> | othermaciej: I was looking for synonyms of figure that started with a d, and settled on <diagram> as well. ^_^ |
| 20:30 | <drunknbass_wor> | i know you can use the img to draw to canvas but how does it know the image size? |
| 20:30 | <drunknbass_wor> | do Image() have property w and h? |
| 20:31 | <Philip`> | They have .width and .height |
| 20:31 | <drunknbass_wor> | oh cool |
| 21:09 | <annevk42> | and, changed |
| 21:10 | <annevk42> | and, IE testing sounds good |
| 21:10 | <annevk42> | and, did you find missing things? e.g. most other UAs support "utf8" as alias |
| 21:11 | <and> | annevk42: Looks fine now. |
| 21:12 | <and> | annevk42: I did not look for missing labels. I did, however, try utf8 since you mentioned it earlier and found that it did *not* work in IE8. |
| 21:12 | <gsnedders> | Anyone have any clue as to the status of html5lib Ruby? |
| 21:13 | <annevk42> | and, k |
| 21:15 | <gsnedders> | Also, and one know how to run the tests for Ruby? |
| 21:20 | <othermaciej> | TabAtkins: I think <diagram> is less good as a name for what <figure> does, enough to make the benefit of d-alignment not worth it |
| 21:20 | <TabAtkins> | othermaciej: I agree, unfortunately. |
| 21:20 | <TabAtkins> | But I also think that <dt>/<dd> in <figure> just feels *retarded*. |
| 21:20 | <TabAtkins> | We should just call it <digure> and be done with it. |
| 21:21 | <Lachy> | haha |
| 21:22 | <othermaciej> | TabAtkins: my own feeling on it was "a little odd", but it's clear that it's created some highly negative reactions |
| 21:23 | <TabAtkins> | It doesn't bother me on the deep level that it seems to for others, but I can definitely understand why they feel that way. |
| 21:24 | <TabAtkins> | <dt>/<dd> are clearly associated with <d*> things. Classically it's <dl>, we had <dialog> for a long time, now <details> (where I think <dt>/<dd> work well), but <figure> is just an odd man out. It feels like a dirty hack where such a hack shouldn't be necessary. |
| 21:24 | tantekc | is glad <dialog> is out |
| 21:24 | <tantekc> | <figure> is also quite a different use-case than <details> |
| 21:25 | <erlehmann> | tantekc, what you say |
| 21:25 | <Lachy> | I wonder if we could expand details to allow multiple dt/dd pairs, similar to dl, where each dt/dd can be opened or closed individually? |
| 21:25 | <othermaciej> | I think a new element to use as a <figure> label is the only other alternative (except maybe <h1>, but <h1> doesn't seem any better than <dt> to me) |
| 21:25 | <Lachy> | though, it would mess with the details.open API |
| 21:25 | <TabAtkins> | I think <h1> doesn't make people angry. |
| 21:25 | <othermaciej> | Lachy: the thought of implementing that makes me cry with sad |
| 21:25 | <erlehmann> | othermaciej, i still dont get what problems occur with <legend> |
| 21:25 | <tantekc> | has someone written up a whatwg wiki page on the options for "heading-like" elements to use as the caption on a figure? |
| 21:25 | <Lachy> | fair enough |
| 21:25 | tantekc | is unable to follow all the email threads |
| 21:26 | <othermaciej> | erlehmann: all browsers currently in use parse <legend> in a way that doesn't give the desired DOM |
| 21:26 | <Lachy> | TabAtkins, I'm not happy about using h1. It's not a heading, it's a caption |
| 21:26 | <erlehmann> | othermaciej, oha. |
| 21:26 | <TabAtkins> | tantekc: No, but I've sort of taken up the torch for writing up that stuff. I meant to start it last weekend, but my internet died on Friday night and still hasn't come back up. |
| 21:27 | <erlehmann> | othermaciej, but WHYYY |
| 21:27 | <othermaciej> | they either drop it entirely, wrap it in a <fieldset>, or insert empty elements named <legend> and </legend> instead of making a legend with content |
| 21:27 | <erlehmann> | urgs |
| 21:27 | <erlehmann> | baaaad |
| 21:27 | <TabAtkins> | Lachy: Sure, but it's still sort of a heading for the included content. |
| 21:27 | <Lachy> | tantekc, othermaciej wrote a nice summarising e-mail that listed most of the options considered |
| 21:27 | <tantekc> | ideally we'd reuse <caption> because that's what people refer to when using figure as a term of speech |
| 21:27 | <Lachy> | I think it was the dt/dd thread |
| 21:27 | <tantekc> | Lachy - yeah, summary emails are also hard to find |
| 21:27 | <TabAtkins> | Yeah, <caption> is really the absolute ideal name. |
| 21:27 | <Lachy> | I will find it |
| 21:27 | <erlehmann> | tantekc, why dont we ? |
| 21:28 | gsnedders | hits issues again with html5lib tests not being JSON despite claiming to be |
| 21:28 | <TabAtkins> | But I believe it dies when you try to use <figure><caption></figure> in a <table>? |
| 21:28 | <erlehmann> | too much elements already? |
| 21:28 | <Lachy> | tantekc, http://www.w3.org/mid/CF65ED73-5D08-4AAD-812B-4DB634E01566⊙ac |
| 21:28 | <tantekc> | erlehmann, precisely the question I'm asking, but email sucks so it is difficult to answer |
| 21:28 | <othermaciej> | anyone who wants to make a blog post out of that email should feel free to do so |
| 21:28 | <erlehmann> | TabAtkins, would that fuck up the DOM as well ? |
| 21:29 | <tantekc> | it should be a wiki page because the info evolves over time |
| 21:29 | <othermaciej> | the specific problem with caption is that browsers drop it outside of tables (same issue as <legend>) and using it anywhere inside a table breaks out of the current cell to the table top level |
| 21:29 | da3d | proposes adding <faption> for figures... |
| 21:29 | <TabAtkins> | <faption><faption><faption> |
| 21:29 | <othermaciej> | I agree that it's the best word match for a figure's caption |
| 21:29 | <Lachy> | using <caption> is even more problematic than <legend> for backwards compatibility reasons. |
| 21:29 | <erlehmann> | FapFapFap |
| 21:29 | <TabAtkins> | I feel dirty typing that. |
| 21:29 | <tantekc> | othermaciej, by "drop" do you mean "display:none" or not in the DOM tree? |
| 21:30 | <othermaciej> | tantekc: not in the DOM |
| 21:30 | <erlehmann> | urgs, not again |
| 21:30 | <othermaciej> | but the table issue is the big one - it would make <figure> unusable in tables |
| 21:30 | <Lachy> | but, I wonder if the parsing could be fixed so that <caption> within <figure> doesn't suffer from the insanity needed elsewhere. |
| 21:30 | <tantekc> | indeed |
| 21:31 | <erlehmann> | <figure><insanity/></figure> |
| 21:31 | <tantekc> | othermaciej - I don't think that's that bad of a problem |
| 21:31 | <othermaciej> | Lachy: it can't be fixed retroactively for legacy browsers |
| 21:31 | <tantekc> | because such tables are likely due to layout anyway |
| 21:31 | <tantekc> | which should be discouraged |
| 21:31 | tantekc | wonders if there is a table of figures use case. |
| 21:31 | <Lachy> | othermaciej, yeah, I know, it sucks for legacy browsers. But as a long term plan for new browsers, I don't see why it couldn't work. |
| 21:32 | <erlehmann> | Lachy, but HTML is legacy aware |
| 21:32 | <Lachy> | though, that doesn't really solve the problem we were trying to avoid with legend |
| 21:32 | <othermaciej> | exactly |
| 21:32 | <erlehmann> | <figure> with <dd><dt> is already out ? |
| 21:33 | <TabAtkins> | Note: the "drops from the DOM" bit of <caption> is crazy! In FF at least it just drops the element, but still inserts the text content at the appropriate place in the DOM. |
| 21:33 | <othermaciej> | the goal is to make figure usable this decade |
| 21:33 | <TabAtkins> | erlehmann: figure>dt just feels horrible. |
| 21:33 | <othermaciej> | TabAtkins: that's what it does in Safari too |
| 21:33 | <othermaciej> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ccaption%3Efoo%3C%2Fcaption%3E |
| 21:34 | <othermaciej> | I think out of the existing elements with some technical difficulties, <label> has the least severe problems |
| 21:34 | <TabAtkins> | I've never been quite sure - is there supposed to be a significant difference between <figure> and <aside>? |
| 21:34 | <Lachy> | TabAtkins, yes |
| 21:35 | <TabAtkins> | I see that <figure> is supposed to be main-flow content that isn't necessarily required to be presented in its given location. |
| 21:35 | <othermaciej> | <figure> is supposed to be roughly for what you could call a figure in print - a picture, chart or table with a caption |
| 21:35 | <Lachy> | a <figure> is for the type of thing that would, for instance, be listed in a Table of Figures commonly found in a book. Asides would never do that |
| 21:35 | <othermaciej> | (though in HTML you could also make it a media item, such as a <video>) |
| 21:36 | <TabAtkins> | I think I might want to do precisely that, though. It's tangentially-related content, right? |
| 21:36 | <othermaciej> | <aside> is what you would use for a sidebar to a magazine article |
| 21:36 | <othermaciej> | or a pull quote |
| 21:37 | <Lachy> | yeah, <aside> is something that is out of the flow of the surrounding content |
| 21:37 | <TabAtkins> | Hmm. I get the distinction, but fear it may be cutting things pretty damn finely. |
| 21:37 | <Lachy> | I really don't see how they are in any way similar |
| 21:38 | <TabAtkins> | Both of them are content that is related to the document, but not in-flow. |
| 21:38 | <othermaciej> | in the print realm you'd never confuse the two |
| 21:38 | <Lachy> | figures are not necessarily out of the flow |
| 21:41 | <TabAtkins> | Actually, I see that it's supposed to always be in-flow, but may be something that could be at least moved out of the text flow for visual reasons. |
| 21:41 | <erlehmann> | like a table of figures at the end of the document |
| 21:41 | <TabAtkins> | As opposed to <aside>, which isn't a part of the content at all, merely related to it in some way. |
| 21:42 | <TabAtkins> | I suppose if I just keep thinking <aside>=<sidebar> I'll be okay. |
| 21:42 | <Lachy> | I wish I could show you an example. But all the ones I'm thinking of are in my old text books from Uni, all of which are back home in Australia |
| 21:43 | <TabAtkins> | Nah, I've got it in my head; I'm thinking of articles from SciAm which are usually chock full of graphs and figures illustrating things in the article. |
| 21:43 | <TabAtkins> | I just dunno if I'll find the distinction useful in practice. |
| 21:44 | TabAtkins | used <dl> in crazy ways in his younger days. |
| 21:44 | <erlehmann> | for styling reasons it sure is |
| 21:44 | <annodomini> | Why can't we just use h1-h6 and/or hgroup for a figure caption? |
| 21:44 | <TabAtkins> | annodomini: That's what I want to do. |
| 21:45 | <Lachy> | because a heading is not a caption |
| 21:45 | <gsnedders> | http://code.google.com/p/html5lib/issues/detail?id=117 |
| 21:45 | <hober> | re: aside v. figure, consider http://www.digital-web.com/articles/coding_for_content/ |
| 21:45 | <TabAtkins> | Lachy, it titles the figure. |
| 21:45 | <Lachy> | and it has to be something that is easy to distinguish from the actual content of the figure, which could conceivably contain its own headings |
| 21:46 | <Lachy> | (that's the reason <figure> is a section root, so that headings that are part of the figure don't affect the outline |
| 21:46 | <TabAtkins> | Lachy: That's easy enough to do by saying that it's the figure>h1:first-of-type |
| 21:47 | <Lachy> | that doesn't work when you want the caption to be at the end |
| 21:47 | <TabAtkins> | So either put the caption before any other <h1>s, or wrap the figure content in something that will make its <h1>s not children of <figure> |
| 21:47 | <Lachy> | that seems like a workaround for a problem that can be avoided |
| 21:48 | <erlehmann> | dt dls ! |
| 21:48 | <erlehmann> | nah i'm drunk |
| 21:48 | <TabAtkins> | Yeah, but other solutions either make people angry (<dt>/<dd>), don't work in legacy browsers (lots of stuff), or are just gratuitous (creating yet another heading element). |
| 21:48 | <Lachy> | othermaciej, did you make any progress with implementing details, like you said you were going to do the other day? I'm curious to see what you came up with for it. |
| 21:49 | <othermaciej> | Lachy: have not had time to work on it, but I intend to give it a crack this weekend |
| 21:49 | <Lachy> | ok, cool. |
| 21:49 | <erlehmann> | TabAtkins, I forsee styling issues with dt and dl too. |
| 21:49 | <Lachy> | will it make it into a webkit nightly soon after? |
| 21:49 | <TabAtkins> | erlehmann: I'm definitely going to have to revise some CSS before I can use <dt>/<dd> in <details> or <figure>. |
| 21:50 | <Lachy> | I expect that will be a common problem for existing style sheets that style dt and dd in ways that won't be appropriate for details or figure |
| 21:51 | <erlehmann> | TabAtkins, why the heck dont we add just another element? i mean, all existing solutions seem to feature insurmountabl obstacles :i |
| 21:51 | <TabAtkins> | erlehmann: Because it's just so dumb to have a dozen different elements that all mean almost exactly the same thing. >_< |
| 21:51 | <Lachy> | because Hixie is being stubbor about that |
| 21:51 | <erlehmann> | TabAtkins, tell that to legacy browsers :P |
| 21:51 | <Lachy> | *stubborn |
| 21:52 | <TabAtkins> | erlehmann: Yeah, and do you want to be the legacy browser people curse in decades to come for implementing one or two *more*? |
| 21:53 | <erlehmann> | TabAtkins, curse your sudden and inevitable long-term planning :D |
| 21:53 | <Lachy> | TabAtkins, I don't get your argument |
| 21:53 | <TabAtkins> | The nice thing about <h1> is that people are *already* going to have to adjust stylesheets if they want to use pure <h1>+<section> stuff. Making them have to handle <h1> in <figure> as well shouldn't be that hard. |
| 21:53 | <erlehmann> | TabAtkins, BUT BROWSERS MADE TODAY ARE PURRFECT |
| 21:54 | <TabAtkins> | erlehmann, OH GOD YOU ARE RIGHT HOW COULD I FORGET |
| 21:54 | <erlehmann> | the bad thing about h1 is that legacy outliners will choke on them |
| 21:54 | <TabAtkins> | That's gonna happen no matter what, though. |
| 21:54 | <erlehmann> | and it will be there in BIG BOLD LETTERS |
| 21:55 | <TabAtkins> | Nobody that relies on legacy outlining algorithms will correctly outline html5 documents. |
| 21:55 | <Lachy> | legacy outliners are irrelevant |
| 21:55 | <erlehmann> | cant we at least say that any heading in a figure is a caption ? then people could safely use <h3> and legacy styling will not be affected |
| 21:55 | <Lachy> | well, almost |
| 21:55 | <erlehmann> | but h1 is HUEG |
| 21:55 | <erlehmann> | like xbox |
| 21:56 | <TabAtkins> | erlehmann, your use of memes is getting ridiculous. ^_^ |
| 21:56 | <Lachy> | (I guess interpretation by screen readers will be the bigest problem since the heading levels will be reported wrongly) |
| 21:56 | <erlehmann> | or put a hgroup in there |
| 21:56 | <erlehmann> | then you have your title-subtitle thingy too for your figure |
| 21:56 | <erlehmann> | also, way to much markup :p |
| 21:56 | <TabAtkins> | Using <figure><h3><more stuff></figure> wont' display dumb, this is true. |
| 21:56 | <TabAtkins> | Alternately: just do what someone else said and use <header>. |
| 21:57 | <TabAtkins> | No outlining issues, no legacy styling issues, no parsing problems that people aren't already willing to deal with. |
| 21:57 | <erlehmann> | TabAtkins, the <caption> is a lie! ;) |
| 21:57 | <da3d> | <header> feels odd if you want to have the caption below the content |
| 21:58 | <erlehmann> | TabAtkins, for consistency, footer too |
| 21:58 | <Lachy> | TabAtkins, using header would just be wrong |
| 21:58 | <TabAtkins> | da3d: it also feels weird to put <footer> at the top of an article. But here we are. |
| 21:58 | <Lachy> | because it would completely different from how its used within section |
| 21:58 | <da3d> | TabAtkins: Does anyone do that? |
| 21:58 | <TabAtkins> | erlehmann: The WHATWG would like to remind you that <caption> hell is real. |
| 21:58 | <TabAtkins> | da3d: No one uses <footer> yet anyway (no one statistically significant), so meh. |
| 21:59 | <TabAtkins> | Lachy: Hmm. You sure? |
| 21:59 | <TabAtkins> | And by that I mean, can you quote me something that shows how I'm dumb? |
| 22:00 | <Lachy> | yes |
| 22:00 | <TabAtkins> | ...man, what *about* <footer>? That sort of not entirely inappropriate. |
| 22:00 | <TabAtkins> | Lachy: Good, because I'm working and can't look up quotes to disprove myself right now. >_< |
| 22:00 | <Lachy> | "The header element represents a group of introductory or navigational aids." - that is completely different from teh concept of a caption |
| 22:00 | <jgraham_> | gsnedders: You planning to fix that bug or just complain? |
| 22:00 | <erlehmann> | TabAtkins, different semantics are fail, Lachy is right with this. |
| 22:01 | <Lachy> | I'm always right :-) |
| 22:01 | <jgraham_> | <h1> is a totally different semantic and sucks much more in legacy browsers, especially AT |
| 22:01 | <Lachy> | agreed |
| 22:01 | <TabAtkins> | "A footer typically contains information about its section" <-- close enough for us to fiddle the text into working? |
| 22:01 | <jgraham_> | You probably shouldn't use the all-<h1> headings thing in the near future for similar reasons |
| 22:02 | <da3d> | Let's just add <stupidbrokencaptionparsers> and be done with it :p |
| 22:02 | <jgraham_> | (You can always use <h1>-<h6> like normal in addition to <section>) |
| 22:02 | <erlehmann> | TabAtkins, This figure problem is impossible. Make no attempt to solve it. |
| 22:02 | <jgraham_> | TabAtkins: <footer> sounds wrong to any and all english speakers |
| 22:03 | <TabAtkins> | Wronger than <dt>/<dd>? |
| 22:03 | <TabAtkins> | I'd put even money on it. |
| 22:03 | <jgraham_> | TabAtkins: The sensible options are <dt>,<dd>, <new> |
| 22:03 | <da3d> | <figtion> |
| 22:03 | <erlehmann> | <fiction> |
| 22:04 | <Lachy> | dt/dd is also wrong and silly for figure. <figtion>, <figcaption>, etc. are terrible names |
| 22:04 | <erlehmann> | jgraham_, is right. <dt> and <dl> are not entirely unreasonable (safe for styling issues) |
| 22:04 | <jgraham_> | TabAtkins: <dt>,<dd> mean <name>,<value>. It's just some old version of HTML used over-short names |
| 22:04 | <Lachy> | <c> and <description> are reasonable names for new elements |
| 22:04 | <TabAtkins> | erlehmann: Remain resolute and resourceful in an atmosphere of extreme pessimism. |
| 22:04 | <da3d> | Lachy: <figtion> wasn't a serious suggestion :p |
| 22:04 | <TabAtkins> | jgraham_, yeah, but that doesn't make them less stupid now. |
| 22:05 | <jgraham_> | If we had <figure><value><img></value><name>My figure</name></figure> there wouldn't be this fuss |
| 22:05 | <Lachy> | jgraham_, yes there would, because the extra wrapper around the value is unnecessary |
| 22:05 | <TabAtkins> | jgraham_: Let's do it then. Throw out <dt><dd> entirely. <dl><name><value>...</dl> 4 life. |
| 22:05 | <jgraham_> | TabAtkins: The reasons they are bad apply equally to <dl> and <details> |
| 22:05 | <erlehmann> | Now you all are just getting silly for the sake of it. |
| 22:06 | <jgraham_> | Lachy: It's odds on that authors will add an extra wrapper half the time anyway |
| 22:06 | <TabAtkins> | jgraham_: No, <dl> and <details> at least have the benefit of mnemonics. The "t" and "d" stand for "title" and "data", obviously. |
| 22:06 | <jgraham_> | Especially for non-<img> cases |
| 22:06 | <Lachy> | if they want that for styling, let them. But don't force everyone to use it |
| 22:06 | <da3d> | <c> works |
| 22:07 | <jgraham_> | TabAtkins: I assumed they stood for "term" and "defenition" |
| 22:07 | <TabAtkins> | Maybe back when dl stood for definition list, sure. |
| 22:07 | <erlehmann> | what jgraham_said |
| 22:07 | <TabAtkins> | also: "definition definition" is just silly. |
| 22:07 | <erlehmann> | Maybe you should marry that <c> since you love it so much. i'd go for <description> |
| 22:07 | <Lachy> | dd now effectively stands for description instead of definition. |
| 22:07 | <jgraham_> | Lachy: I'm not arguing it's the best solution. But it is whole lot better than what we had before yet there is more fuss now |
| 22:08 | jgraham_ | would have minted a new element years ago |
| 22:09 | <TabAtkins> | jgraham_ I think nobody really expected to *use* <figure> while it had <legend>. Now that it's suddenly possible to use, we're fussing about it not being good enough. |
| 22:09 | <erlehmann> | I used it. Foolishly, i know. |
| 22:09 | <erlehmann> | A simple regex over my blog will fix it as soon as a new element comes. |
| 22:10 | <TabAtkins> | Shame on you, erlehmann. |
| 22:11 | <Lachy> | another possible alternative, though I admit not well thought out, would be to use <p caption>...</p>. No parsing issues, and the caption attribute identifies it as being a caption. |
| 22:11 | <TabAtkins> | I have a big list of sections in our software and bugs that have been fixed in each section. Appropriate to use <dl>? Or should I just stick with <h3> and <ul>? |
| 22:11 | <jgraham_> | Yeah well that's just silly. People would have let the spec go to LC with <legend> which was broken-by-design but will go up in arms once there is an imperfect but not broken design in place |
| 22:11 | <TabAtkins> | Lachy: Hmm. It has the nice parallel with <time pubdate> in being metadata about it's appropriate ancestor. |
| 22:12 | <TabAtkins> | jgraham_, I'm not saying people aren't silly. I'm just saying that's what I think's going on. |
| 22:12 | <erlehmann> | Lachy, dont new element semantics come to abolis attributes? |
| 22:12 | <TabAtkins> | erlehmann: No, they abolish *classes* |
| 22:12 | <erlehmann> | noticed. |
| 22:12 | <jgraham_> | Lachy: pushing semantics to attributes is something that HTML traditionally avoids |
| 22:12 | erlehmann | scribbles furiously on his SPY NOTEPAD. |
| 22:12 | <Lachy> | I didn't say it was a good idea. :-) |
| 22:13 | <TabAtkins> | I sorta like it, shrug. |
| 22:13 | <TabAtkins> | Better than <c>, at least. |
| 22:13 | TabAtkins | may just be channeling his love for binary attributes. |
| 22:14 | <erlehmann> | a want a <description> |
| 22:14 | <jgraham_> | Also, if one more person says "I looked in a thesaraus and we should call it <rubric>" I will go spare |
| 22:14 | TabAtkins | goes ahead and uses <dl> for his problem. |
| 22:14 | <TabAtkins> | I don't even know what rubric means. |
| 22:14 | <jgraham_> | hint: if you hd to look up the word it's not sufficiently obvious |
| 22:15 | <TabAtkins> | And I've got a big vocabulary. |
| 22:15 | <jgraham_> | In fact a rubric isn't typically a figure caption. It's a set of instructions on an examination paper |
| 22:15 | <jgraham_> | So it doesn't even mean the right thing |
| 22:16 | <jgraham_> | (at least that is the only context in which I have actually heard it used) |
| 22:16 | <tantekc> | erlehmann, the <meta> is a lie. |
| 22:16 | <TabAtkins> | tantekc: That's because it's invisible metadata, and has drifted out of sync with the text. |
| 22:16 | <othermaciej> | <rubric> is not particularly apposite |
| 22:16 | <othermaciej> | but then again, neither was <legend> |
| 22:16 | <Lachy> | rubric: "A part of a manuscript or book, such as a title, heading, or initial letter, that appears in decorative red lettering or is otherwise distinguished from the rest of the text." |
| 22:17 | <TabAtkins> | ?_? |
| 22:17 | <tantekc> | perhaps a <longdesc> element to replace the longdesc attribute. ;) |
| 22:17 | <erlehmann> | Lachy, sounds liek metadata. |
| 22:17 | <jgraham_> | Lachy: Yeah I jut saw the same thing. It seems to be some histoical publishing convention |
| 22:17 | <jgraham_> | *historical |
| 22:18 | <erlehmann> | tantekc, stop suggesting things. |
| 22:18 | <tantekc> | or I suppose it doesn't have to be long |
| 22:18 | <tantekc> | so just <desc> then |
| 22:18 | <erlehmann> | a <longdesc> element would look horrible urgs |
| 22:18 | <erlehmann> | <desc> \o/ |
| 22:18 | <tantekc> | in the custom of oblique four letter abbrs for HTML tag names |
| 22:19 | <erlehmann> | yeah, like <inpu> :D |
| 22:19 | <erlehmann> | and <butt> |
| 22:19 | tantekc | wonders if there is a histogram of HTML element name lengths. |
| 22:19 | TabAtkins | giggles - he couldn't help himself. |
| 22:20 | <erlehmann> | There is a special hell reserved for you web developers. Just so you know. |
| 22:20 | <TabAtkins> | You're welcome. |
| 22:21 | <Lachy> | we can't use <desc> because it clashes with SVG |
| 22:21 | <tantekc> | erlehmann, I think the level for language developers is nested a bit deeper than that. |
| 22:21 | <tantekc> | Lachy, what does <desc> mean in SVG? |
| 22:22 | <virtuelv> | oh, on the term "metadata", this is a worthwhile read: http://blogs.fluidinfo.com/fluidDB/2009/09/05/metadata-vs-data-a-wholly-artificial-distinction/ |
| 22:22 | <Lachy> | it's a description for something, but the issue is that the parsing algorithm needs to put the element into the right namespace |
| 22:22 | <virtuelv> | (not all of it is directly relevant to a markup language) |
| 22:22 | <erlehmann> | name-space. shhhh, ian better not hear this. |
| 22:23 | <tantekc> | virtuelv - nice post |
| 22:23 | <tantekc> | Lachy, "right namespace" ? why? |
| 22:23 | <tantekc> | so when the parser finds a <desc> inside a <figure> then it can treat it properly |
| 22:24 | <erlehmann> | virtuelv, i prefer metacrap by doctorow, to end a debate like this: http://www.well.com/~doctorow/metacrap.htm |
| 22:24 | <erlehmann> | tantekc, who says that you wont use figures to mark up SVG images, huh ? |
| 22:24 | <tantekc> | and Lachy, if "right namespace" is an issue, how do you deal with svg:a vs html:a ?? |
| 22:24 | <jgraham_> | tantekc: Having element names that overlap is bad form. Where SVG has overlapped with HTML has caused us problems trying to integrate them |
| 22:24 | <annevk42> | wow, journalists epically fail in sarcasm -- http://news.cnet.com/8301-30684_3-10355860-265.html |
| 22:24 | <jgraham_> | e.g. <textArea> |
| 22:25 | <tantekc> | jgraham - yeah, that was a tough lesson for SVG to learn wasn't it? |
| 22:26 | tantekc | would love to see the internal debate / process for who / however it was decided to create svg:a that's mostly like html:a but uses something more complex (XLink) to achieve the same functionality. |
| 22:26 | <erlehmann> | tantekc, a special hell |
| 22:26 | <Hixie> | tantekc: i imagine the debate was "ok we need a linking element." "we should use xlink!" "yeah!" "ok, done." |
| 22:26 | <tantekc> | erlehmann, the <desc> would be inside the <figure> but not the nested <svg> |
| 22:27 | <tantekc> | Hixie, I vaguely recall Chris Lilley saying something about not wanting to burden SVG authors with having to import the XHTML namespace just to be able to link to something. |
| 22:27 | <Hixie> | ... |
| 22:27 | <tantekc> | <cough>multi-namespace fail in practice</cough> |
| 22:28 | <Philip`> | So instead they have to import the XLink namespace just to be able to link to something? |
| 22:28 | <Hixie> | tantekc: btw i sent the payment to w3c for you, me, and the others google is paying for |
| 22:28 | <Hixie> | tantekc: so we should be all set |
| 22:28 | <Hixie> | tantekc: let me know if anyone suggests you haven't paid and i'll come wack them over the head |
| 22:29 | <tantekc> | but Philip`, XLink is clean XML architecture! None of that messy hacky (X)HTML nonsense. |
| 22:29 | tantekc | is grateful for his corporate sponsor. |
| 22:29 | <erlehmann> | i'm gone |
| 22:29 | <tantekc> | /me is now looking for funding for the W3C CSS WG days... |
| 22:29 | <Lachy> | my attendance at tpac is still undecided, though I will find out by some time next week I think |
| 22:30 | <Hixie> | tantekc: fee goes up in like 4 days, fwiw |
| 22:30 | <Hixie> | from $50/day to $75/day |
| 22:30 | <Hixie> | (still can't believe we're being charged to attend, it's so ridiculous) |
| 22:31 | <Lachy> | yeah, in that case, my attendance will be decided before the price goes up. If it's not, I doubt I will be going. But I hope I am |
| 22:31 | tantekc | thinks they should have named it Technical Update, Plenary, Advisory Committee meeting |
| 22:31 | <Lachy> | haha |
| 22:32 | <TabAtkins> | tantekc, hahaha |
| 22:34 | <Hixie> | did maciej ever send his summary of the telecon from last week? |
| 22:34 | <Hixie> | he told me he was planning on sending summaries, separate from minutes, but i don't recall seeing any |
| 22:34 | <Hixie> | maybe the telecon didn't do anything to summarise... |
| 22:36 | <tantekc> | maybe it was in a <caption> element outside of a table and thus dropped... |
| 22:43 | <Hixie> | you know for someone who's not a wg member shelley sure sends a lot of e-mail to the wg |
| 22:44 | <TabAtkins> | Why isn't she a wg member? Does she have a reason? |
| 22:44 | <hober> | TabAtkins: she periodically joins and leaves the WG, but that doesn't seem to affect her level of participation. |
| 22:44 | <Lachy> | TabAtkins, because she can't stand working with the group |
| 22:44 | <TabAtkins> | That's... odd. |
| 22:45 | <TabAtkins> | For both of those. |
| 22:45 | <hober> | it's sort of a moth/flame thing |
| 22:54 | tantekc | withholds comments about sending lots of emails and what that does or does not imply. |
| 22:54 | <jamesr> | Hixie: as a meta-point on the storage mutex, it seems like it's a bad idea to encourage browser venders to ship major releases with not-fully-baked spec implementations if that short-circuits the rest of the spec process |
| 22:54 | <gsnedders> | jgraham_: Mainly just complain. |
| 22:54 | <jamesr> | while it's great to get UA feedback it's not so great if that becomes the end of the entire process |
| 22:55 | <jamesr> | maybe specs should be namespaced until there's some degree of consensus that it could work out? |
| 22:55 | <jamesr> | i'm sure this has been hashed through before (i'm a bit new to the w3 working group process) but there are way too many web standards and de facto web standards that are complete shite but unchangable because browser X shipped a major release with it and then got market share |
| 22:56 | <annevk2> | the theory that worked so far is that if there's more than 2 impl it's good enough |
| 22:56 | <jamesr> | 1 impl seems to be enough if it ships as a 'major' release |
| 22:56 | <annevk2> | that is, it gave both reasonable quality and progress |
| 22:57 | <annevk2> | jamesr, no |
| 22:57 | <annevk2> | jamesr, e.g. globalStorage which Firefox shipped with is gone |
| 22:57 | <jamesr> | yeah, but according to Hixie's email the localStorage API is set in stone because IE8 shipped with it |
| 22:57 | <annevk2> | not just IE |
| 22:57 | <annevk2> | also Firefox and Safari |
| 22:58 | <jamesr> | that's not what his email said |
| 22:58 | <tantekc> | whoa really? |
| 22:58 | <annevk2> | jamesr, I guess it didn't list all the reasons then |
| 22:59 | <annevk2> | and arguments |
| 22:59 | <jamesr> | "However, localStorage is more or less fixed because Microsoft shipped it and their release cycle means they won't ship changes to it before it is solidly embedded in too many sites to risk changes." |
| 22:59 | <tantek> | HTML5 is already being saddled by legacy implementations of the *new* stuff? |
| 22:59 | <gsnedders> | tantek: That happened a while ago. |
| 22:59 | <annevk2> | I shouldn't say "I guess", I read the email |
| 23:01 | <jamesr> | annevk2: it doesn't seem like the other implementors (Mozilla/Apple) are in love with the current API either |
| 23:01 | <tantek> | jamesr - re: namespaced. there is vendor prefixing in CSS to reduce this kind of problem there: http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords |
| 23:02 | <jamesr> | tantek: right - why not use that for all new APIs before they get a bit of bake time? if a vendor shipped the 'document.experimentalLocalStorage API' then i don't think anyone would be quite so worried about mucking with it |
| 23:03 | <annevk2> | jamesr, I guess not |
| 23:04 | <jamesr> | the situation now means that even if everyone has the best intentions and does everything right there's still a chance that we get stuck with a bad API and can never ever fix it |
| 23:04 | <annevk2> | you always have that |
| 23:04 | <jamesr> | you can try to discourage it |
| 23:05 | <annevk2> | even if you have bake time it can still happen |
| 23:05 | <annevk2> | e.g. localStorage has been around for a long time |
| 23:05 | <annevk2> | it's only recently that it attracted fierce opponents |
| 23:05 | tantekc | notes that the CSS vendor prefixes are not bound to URLs. |
| 23:06 | <tantekc> | annevk2 - the CSS vendor prefixes have allowed experimenting without saddling with legacy. |
| 23:06 | <tantekc> | especially in some particularly difficult/useful areas like border-radius etc. |
| 23:06 | <tantekc> | nevermind animations and transforms |
| 23:06 | <jamesr> | but you can't, as a browser developer, experiment with new APIs without running the risk of locking it into place |
| 23:06 | <annevk2> | CSS vendor prefixes are scattered around all over the Web |
| 23:06 | <gsnedders> | jamesr: There's a fair amount of unwillingness to change -moz-border-radius to match the current spec, IIRC. The problem arises once something is widely used, whether or not it is prefixed. (Although it is true that in the long-run a non-prefixed version could work.) |
| 23:06 | <annevk2> | and we actually get bug reports on them |
| 23:06 | <tantekc> | annevk2 - right, but they are not preventing "proper" use of non-prefixed keywords |
| 23:06 | <annevk2> | (for the -moz- and -webkit- ones) |
| 23:07 | gsnedders | blinks |
| 23:07 | <gsnedders> | seriously!? |
| 23:07 | <gsnedders> | wow. |
| 23:07 | <jamesr> | gsnedders: but that's better than if it had been border-radius from the beginning. then there would be no possibility to change border-radius |
| 23:07 | <tantekc> | precisely jamesr |
| 23:07 | <gsnedders> | jamesr: Then Moz ends up with two impls, which is less than ideal |
| 23:08 | <tantekc> | gsnedders, the ideal is the enemy of the quite good. |
| 23:08 | <gsnedders> | Then you get into the debates about when to remove the prefix |
| 23:08 | <tantekc> | gsnedders - I call theoretical |
| 23:08 | <annevk2> | I'm not really convinced CSS is that comparable |
| 23:08 | <tantekc> | gsnedders - I haven't seen anything like that in CSS |
| 23:08 | <annevk2> | for one there's often experimental CSS around without a public spec that already received a bunch of attention |
| 23:08 | <gsnedders> | tantekc: I have. |
| 23:09 | <tantekc> | annevk2 - the DOM APIs could have similarly had x- prefixes |
| 23:09 | <annevk2> | so the new properties have received far less public scrutiny compared to say localStorage |
| 23:09 | <tantekc> | the history of using vendor prefixes is quite old actually |
| 23:09 | <tantekc> | IETF x- stuff |
| 23:09 | <annevk2> | and therefore it's all the more likely it'll change |
| 23:09 | <tantekc> | not sure why the markup folks have not used it... |
| 23:09 | <annevk2> | x- stuff is also an epic fail imo |
| 23:09 | <jamesr> | gsnedders: i agree that -vendor-prefix is not perfect but i think it's better |
| 23:09 | <gsnedders> | tantekc: For one example, look at some of the comments on IE8 prefixing IE-origin CSS3 properties |
| 23:09 | <annevk2> | there's x- stuff all over the place |
| 23:09 | <annevk2> | that you actually need to use and cannot be changed to x-less |
| 23:10 | <tantekc> | annevk2 - x- stuff gradually transitions to non x- |
| 23:10 | <tantekc> | e.g. image/png |
| 23:10 | <gsnedders> | tantekc: There are some x prefixed charset names that have been around for decades for which support is still eeded |
| 23:10 | <tantekc> | there's always going to be early "x-" stuff that hasn't matured to the point of not needing a prefix - that's how the system works |
| 23:10 | <tantekc> | gsnedders, like for example? |
| 23:11 | <tantekc> | with what stats? |
| 23:11 | <annevk2> | x-x-big5 is pretty widely used |
| 23:11 | <annevk2> | as is x-euc-jp or some such |
| 23:11 | <annevk2> | x-mac-roman etc. |
| 23:11 | <tantekc> | start writing that stuff up on a wiki with URLs to examples and I'll believe you |
| 23:11 | <tantekc> | otherwise it's just hearsay |
| 23:11 | <Hixie> | jamesr: not much we can do about it |
| 23:11 | <annevk2> | see philip's charset stats and see web encodings on the WHATWG Wiki |
| 23:11 | tantekc | gave up arguing with theoretical (or undocumented) examples |
| 23:12 | <annevk2> | HTML form submission uses an x- prefixed media type |
| 23:12 | <gsnedders> | tantekc: http://philip.html5.org/data/charsets.html#charset-x-euc-jp |
| 23:12 | <gsnedders> | tantekc: There's a list of URLs. |
| 23:12 | <tantekc> | thank you gsnedders |
| 23:13 | <annevk2> | Microsoft recently spread an x-ua-compatible all over the Web |
| 23:14 | annevk2 | is not a fan of prefixes |
| 23:14 | <annevk2> | (well, except when it's truly experimental, but it hardly ever is) |
| 23:14 | <annevk2> | (usually it's just to hard to register a name) |
| 23:15 | <jamesr> | Hixie: :( |
| 23:15 | <tantekc> | annevk2 "recently" is part of how x- works - that's not a criticism. |
| 23:16 | <annevk2> | it is |
| 23:16 | <annevk2> | x- is for experimental purposes, not for widescale deployment |
| 23:18 | <tantekc> | experimental is orthogonal to widescale |