| 01:47 | <GPHemsley> | Anyone know the status of css-content? |
| 02:12 | <Hixie> | GPHemsley: i was just asking about that. status seems to me orphaned. |
| 02:24 | <zewt> | ... a=Object(); b=Object(); c=Map(); c[a] = 1; c[b] = 2 <- c[a] == c[b] == c["[object Object]"] in FF. isn't the whole damned *point* of Map that it uses objects as keys and not strings? |
| 03:36 | GPHemsley | wonders if TabAtkins is looking for another spec to edit |
| 03:47 | <GPHemsley> | oh, apparently that was also discussed recently |
| 03:48 | <GPHemsley> | in other news, the abbreviation for GitHub sometimes confuses me |
| 03:48 | <GPHemsley> | (good thing it's not GitPageHub or something) |
| 04:00 | <Domenic_> | zewt: map doesn't change how [] works in JS. Use map.set and map.get |
| 04:04 | <zewt> | that's worthless |
| 04:07 | <zewt> | introducing a new container class before designing a way to make that work the way every programmer is going to expect is nonsensical |
| 04:21 | <Domenic_> | i think it would be a much worse wtf if all of a sudden [] no longer accessed properties of an object but instead some magical data store where objects could be keys |
| 04:22 | <Domenic_> | map["constructor"] // wtf this is undefined because nobody set it? i just want the constructor! |
| 04:33 | <zewt> | doesn't seem any stranger than any other custom getter/setter; it seems exceptionally strange (and confusing) to have a native map class that doesn't work with getter syntax |
| 07:22 | <Domenic_> | properties are always strings; breaking that assumption would break so many programs |
| 09:48 | <SimonSapin> | GPHemsley, Hixie: http://dev.w3.org/csswg/css-content/ has a big red obsoletion notice |
| 09:49 | <SimonSapin> | … which is not on http://www.w3.org/TR/css3-content/ for bad reasons |
| 11:09 | <crocket> | ,school |
| 11:09 | <crocket> | 'school |
| 11:09 | <crocket> | `school |
| 11:09 | <crocket> | where was I/ |
| 11:10 | <Ms2ger> | School, perhaps? |
| 11:10 | <crocket> | yes |
| 11:10 | <crocket> | I want to be presented with HTML/CSS learning materials. |
| 11:10 | <crocket> | I was given them with school command. |
| 11:11 | <crocket> | I don't remember which channel had that command. |
| 11:11 | <crocket> | ,help |
| 11:11 | <crocket> | 'help |
| 11:11 | <crocket> | `help |
| 11:11 | <crocket> | nothing |
| 11:11 | <Ms2ger> | Not this one, definitely |
| 13:56 | <GPHemsley> | SimonSapin: Meaning, it should be on the TR version, too? |
| 13:56 | <SimonSapin> | yes |
| 13:56 | <Ms2ger> | glwt |
| 13:56 | <SimonSapin> | AFAIU nobody has bothered to go through W3C bureaucracy to change a publish document without making a new publication |
| 14:23 | <zewt> | Domenic_: it would break zero programs, because we're talking about a new API |
| 18:54 | <GPHemsley> | is there a single list of pseduo-elements? (are there really not that many?) |
| 18:59 | <SimonSapin> | GPHemsley: there is four defined here: http://www.w3.org/TR/selectors/#pseudo-elements |
| 18:59 | <SimonSapin> | I believe they’re the only ones consistently implemented |
| 18:59 | <SimonSapin> | ::selection was removed from the spec |
| 18:59 | <SimonSapin> | a bunch of proposals add more, eg. http://dev.w3.org/csswg/css-overflow/#fragment-pseudo-element |
| 19:00 | <SimonSapin> | and some implementations have a bunch of proprietary pseudo-elements for various things |
| 19:01 | <SimonSapin> | eg. https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Mozilla_Extensions#Pseudo-elements_and_pseudo-classes |
| 19:07 | <GPHemsley> | hmm, thanks |
| 23:12 | <jgraham> | zewt: Yeah, it does often seem that TC39 are big on consistency and bad on usability. It isn't obvious why you couldn't add the ability to override the meaning of [] in particular classes and use that to make map less user hostile |
| 23:19 | <Domenic_> | you would be unable to pass a Map into a lot of existing code that assumes existing object keys are strings. |
| 23:21 | <zewt> | so? |
| 23:22 | <zewt> | can't think of any case in any code i've ever written where that would matter more than having a map interface that isn't gross |
| 23:24 | <zewt> | and it trades for being able to use the class in tons of existing code that assumes object keys are the keys of the dictionary |
| 23:25 | <zewt> | function sum_values(dict) { var total = 0; for(var key in dict) total += dict[key]; return total; } |
| 23:25 | <zewt> | would work for both types, instead of having to write separate code for maps with their different interface |