# [11:14] <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

# [11:46] <hsivonen> MikeSmith: I *think* it means that character c is a compatibility character if NFD(c) != NFKD(c)

# [11:46] <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."

# [11:47] <hsivonen> annevk2: why is that SHOULD in all caps but the one I quoted isn't?

# [14:34] <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

# [14:34] <Lachy> you're obviously not on earth then, where multiplication is a numeric operation, not string concatenation

# [14:34] <jgraham_> Lachy: Seriously, if I need a string with 500 a's in it, what syntax would you suggest?

# [14:42] <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

# [14:42] <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

# [14:43] <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

# [14:44] <Lachy> jgraham_, yeah, but you have to know the types, which doesn't work in this case:...

# [15:02] <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

# [15:03] <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

# [15:03] <takkaria> Lachy: well, you don't, because as you note, it can do anything

# [15:03] <takkaria> you have to then go look up the class in question

# [15:03] <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)

# [15:21] <erlehmann> Lachy, or use the preprocessor to make TRUE to FALSE and vice versa -- maintainer fun :D

# [15:21] <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

# [15:21] <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)

# [15:24] <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

# [15:24] <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

# [15:25] <Philip`> C++ using bit-shift operators from stream IO isn't much weirder than Python using the modulo operator from string interpolation

# [17:40] <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

# [17:40] <TabAtkins> Lachy: Heh, I was just in the middle of typing exactly that.

# [17:41] <Lachy> and that's a little problematic if you want to set default styles for section, and then override them based on the level

# [17:41] <Lachy> and I'd rather not have :section() pseudo-class and a ::section pseudo-element to cover both cases

# [17:41] <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.

# [17:42] <TabAtkins> And you wouldn't have to distinguish between explicit <article>/<section>/etc

# [17:42] <TabAtkins> Of course, this would absolutely require the relaxation of the "only one pseudoelement, and only at the end" requirement.

# [17:49] <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.

# [17:49] <Lachy> TabAtkins, takkaria, one of you has to change your name. You're messing with my autocomplete! :-)

# [17:50] <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.

# [17:51] <takkaria> public-html was getting reasonably technical before this dt thread came along

# [17:52] <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.

# [18:33] <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.

# [18:48] <gsnedders> gavin: I just always fail to think of how to say stuff in French, though I'm fine when given French to read.

# [18:49] <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

# [18:50] <gavin> so its easy to lose familiarity with phrasing/expressions/etc.

# [18:51] <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

# [19:14] <Rik|work> MikeSmith: there's a backlog with IRC, not with CB

# [19:14] <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

# [19:14] <TabAtkins> The nice thing about tweets is that they are relatively permanent and searchable, unlike your average IRC room.

# [19:14] <othermaciej> it's a wonder that it hasn't been either replaced or properly specified by RFC

# [19:14] <Philip`> so naturally I had 24pt magenta Comic Sans on a yellow background

# [19:14] <erlehmann> Rik|work, there is a backlog on entry with Jabber MUC

# [20:18] <TabAtkins> I've got a js parser built for it that just swaps the <pre> out for an equivalent <table>.

# [20:19] <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.

# [20:27] <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>.

# [20:33] <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

# [21:24] <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.

# [22:32] <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.

# [22:37] <tantekc> it should be a wiki page because the info evolves over time

# [22:37] <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

# [23:01] <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.

# [23:19] <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.

# [23:19] <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>?

# [23:19] <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

# [23:19] <TabAtkins> Lachy: Hmm. It has the nice parallel with <time pubdate> in being metadata about it's appropriate ancestor.

# [23:24] <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."

# [23:34] * 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.