| 00:08 | <SamB> | so no crypto-quality RNG, either? |
| 00:19 | <SimonSapin> | annevk: I made 'decode' a method of Encoding objects in my python implementation. It’s a bit weird when the object is actually ignored because of a BOM |
| 00:20 | <SimonSapin> | the alternative is to have functions and Encoding objects as parameters, but it’s more stuff to import |
| 00:21 | <Hixie> | gsnedders: oh absolutely, but the topic was exposing GC behaviour :-) |
| 00:22 | <Hixie> | gsnedders: i completely agree that we expose all kinds of other crazy behaviour |
| 00:22 | <Hixie> | not least of which, with anything that touches the network... |
| 00:23 | <SamB> | or most things that involve the IETF? |
| 05:16 | <JonathanNeal> | http://www.4dsolutions.net/ocn/cardinality.html |
| 05:18 | <JonathanNeal> | Depends if you're referring to the collection as a value, like the length of keys, or the numbers themselves as things being ordered … sounds like you want the latter - so ordinality works. |
| 12:58 | <gsnedders> | Hixie: My point was mostly that caching behaviour does expose GC behaviour, and this is what everyone who's optimized like that has done. |
| 12:58 | <gsnedders> | SamB: crypto-quality RNG isn't exposing non-determinism in an API that should have none |
| 18:04 | <SamB> | gsnedders: so by "expose" do you mean something more like "provide access to information that can be used for evil", or "uncover sharp corners for people to injure themselves upon"? (And does this mean you think explicit weak references would also be bad?) |
| 19:55 | <Hixie> | gsnedders: yeah, true |
| 19:56 | <zewt> | SamB: (that's why WeakMap isn't iterable) |
| 20:40 | <annevk> | Hixie: my idea was to use any <th> elements in the first row |
| 20:42 | <annevk> | SimonSapin: I don't understand what you said above |
| 20:43 | <Hixie> | annevk: yeah, i guess we could use the <th> elements of the first row if there's no <thead>, and if you want something more complicated, you have to use <thead> |
| 20:43 | <annevk> | Hixie: right, that would save me a bunch of typing :) |
| 20:44 | <SimonSapin> | annevk: get_encoding('label').decode(input) vs. decode(input, get_encoding('label')) |
| 20:44 | <Hixie> | annevk: a whole 14 characters! |
| 20:44 | <Hixie> | annevk: (i always use <thead> because it makes styling easier) |
| 20:44 | <SimonSapin> | although the latter can be abbreviated as decode(input, 'label') |
| 20:45 | <SimonSapin> | with functions the parameter can be name fallback_encoding, which makes more sense because of BOM detection |
| 20:45 | <annevk> | SimonSapin: oh I see, you can do that I suppose, but you should also have a way to implement the decode() from the spec if you want to implement CSS and such ;) |
| 20:45 | <annevk> | the decode algorithm, I mean |
| 20:45 | <SimonSapin> | annevk: yes, this is the decode algorithm |
| 20:46 | <SimonSapin> | the question is where do I put it |
| 20:46 | <annevk> | well there's a decoder per encoding and there's a more general algorithm that takes into account a bom and treats the label as a fallback in case there's no BOM |
| 20:47 | <annevk> | SimonSapin: seems you're right about the encoding's name thingie, guess I'll fix that now |
| 20:47 | <SimonSapin> | is it useful to expose the lower-level decoders? |
| 20:50 | <annevk> | SimonSapin: there's a few times where other specs (at the moment) directly invoke the lower-level decoder |
| 20:51 | <annevk> | SimonSapin: I guess ideally we should clean that up in due course and document the entry points more clearly, but for now I'm still figuring out what the actual requirements are |
| 20:51 | <SimonSapin> | annevk: I’ll keep this for now, and add the lower level decoders later if needed |
| 20:52 | <SimonSapin> | but they’re just python’s anyway |
| 20:52 | <zewt> | quotostrophes |
| 20:52 | <annevk> | well it's still important, people will look at that code down the road and learn from it |
| 20:53 | <SimonSapin> | annevk: do you have example of other specs using the lower-level decoder? |
| 20:54 | <annevk> | SimonSapin: URL |
| 20:55 | <annevk> | but maybe I should a "bomless decode" entry-point for that |
| 20:57 | <SimonSapin> | annevk: WIP: http://packages.python.org/webencodings/ |
| 20:58 | <annevk> | Hixie: I was wondering about that point you made the other day. Since "notification" has a plural it should be "notifications"... Should "url.spec.whatwg.org" become "urls.spec.whatwg.org" then? Maybe later? |
| 20:59 | <annevk> | SimonSapin: wow cool |
| 21:01 | <annevk> | SimonSapin: why is there get_encoding? seems redundant |
| 21:01 | <SimonSapin> | annevk: I’ll probably remove lookup or make get_encoding internal/undocumented |
| 21:04 | <annevk> | Hixie: same for Encoding... |
| 21:04 | <annevk> | Hixie: IETF apparently calls that "charset" these days, so weird |
| 21:05 | <SimonSapin> | annevk: I thought there was only one :) http://encoding.spec.whatwg.org/#the-encoding |
| 21:05 | <annevk> | SimonSapin: sssh don't tell anyone ;) |
| 21:06 | <SimonSapin> | annevk: I guess that "charset" is from the days when different encodings always had a different set of supported charcters |
| 21:06 | <SimonSapin> | which is still kind of true, but not with UTF-* |
| 21:06 | <annevk> | yeah is, but see http://lists.w3.org/Archives/Public/public-html/2012Nov/0188.html |
| 21:07 | <SimonSapin> | oh well … |
| 21:07 | <annevk> | and in particular http://tools.ietf.org/html/rfc6365 referenced later in that thread |
| 21:12 | <SimonSapin> | that RFC actually has different definitions for "character encoding scheme" and "charset" |
| 21:13 | <SimonSapin> | can we say that "encoding" is short for "character encoding scheme" and move on? |
| 21:14 | <annevk> | Encoding defines its terms from primitives so it's fine I think |
| 21:15 | <annevk> | I think "encoding" is fine personally, if we have to make it different at some point, I guess it would be "text encoding" because of the API |
| 21:15 | <Hixie> | annevk: i wouldn't bother changing any of them at this point :-) |
| 21:20 | <annevk> | Hixie: sorting-enable table element -> sorting-enable*d* table element |
| 21:21 | <Hixie> | thanks |
| 21:21 | <annevk> | Hixie: also, all the mutation stuff you want to define in terms of concept-node-append etc. so that mutation observers are well defined |
| 21:22 | <Hixie> | yeah |
| 21:22 | <Hixie> | are parser notifications batched in any way? |
| 21:22 | <Hixie> | i don't want to have to resort the table with every token/character inserted by the parse... |
| 21:23 | <annevk> | parser mutations are not defined to that extent as they depend on network latency and such... |
| 21:23 | <Hixie> | they only depend on network latency if we do batch |
| 21:24 | <Hixie> | so i assume that means we batch |
| 21:25 | <annevk> | yeah |
| 21:25 | <annevk> | shouldn't sorting start after </table>? |
| 21:25 | <Hixie> | not if there's a render between the <Table> and the </table> |
| 21:25 | <Hixie> | otherwise you'll get flicker |
| 21:26 | <annevk> | you'll get that either way no? |
| 21:26 | <Hixie> | if you sort before you render, no |
| 21:27 | <Hixie> | (if the table is so big you get multiple renders before it's parsed, then sure) |
| 21:27 | <Hixie> | (but they'll look like insertions, not reordering) |
| 21:27 | <Hixie> | (so it's not so bad) |
| 21:27 | <annevk> | but they'll be insertions at random places, which might be worse than bad |
| 21:28 | <Hixie> | not random at all |
| 21:28 | <Hixie> | insertions in the appropriate places to maintain order |
| 21:28 | <annevk> | e.g. stuff from the end might end up on top and if the table is very big you might have already scanned past that |
| 21:28 | <annevk> | seems kinda weird |
| 21:28 | <Hixie> | if the table is so big as to have multiple renders, it'll be pretty obvious pretty quickly that it's still loading |
| 21:29 | <Hixie> | whereas if you only sort once, you really might have read the top of the table before it sorts |
| 21:29 | <SimonSapin> | annevk: anything else before I release python-webencodings 0.1? |
| 21:30 | <annevk> | SimonSapin: I don't like the web prefix, but that's aesthetics |
| 21:30 | <SimonSapin> | annevk: the point is that python supports loads of labels, but for the web you want a specific set of labels |
| 21:31 | <SimonSapin> | Other encodings not listed could have their use in non-web context |
| 21:31 | <annevk> | I know, but I want this to be used beyond the web |
| 21:32 | <SimonSapin> | For the web it’s a feature not to have an API to add encodings. In other contexts maybe not |
| 21:32 | <annevk> | Hixie: the current algorithm also doesn't seem to take into account there could be further parser changes |
| 21:33 | <Hixie> | hm? |
| 21:33 | <Hixie> | the current algorithm isn't close to complete |
| 21:33 | <Hixie> | it doesn't even sort yet :-P |
| 21:33 | <Hixie> | nor move any rows |
| 21:33 | <annevk> | Hixie: e.g. it seems like it might fail for <table sortable><thead><tr> { long wait } <th> |
| 21:33 | <annevk> | mkay |
| 21:33 | <Hixie> | why would it fail for that? |
| 21:34 | <annevk> | well I guess it depends on how often table sorting algorithm is invoked |
| 21:34 | <annevk> | I'll be patient :) |
| 21:35 | <Hixie> | it shouldn't matter how often it's invoked |
| 21:35 | <annevk> | it's observable via the sort event |
| 21:35 | <Hixie> | same as mutation events, sure |
| 21:36 | <Hixie> | er |
| 21:36 | <Hixie> | observers |
| 21:36 | <SimonSapin> | annevk: I’m not against changing the name but now is the time :) At least for this python implementation, I think it’s only useful for legacy web content (hence the current name). Otherwise just use python’s stdlib |
| 21:38 | <annevk> | SimonSapin: seems http://packages.python.org/encoding/ is available ;) |
| 21:38 | <annevk> | SimonSapin: I'd aim to become the stdlib |
| 21:38 | <SimonSapin> | hehe |
| 21:38 | <SimonSapin> | one step at a time |
| 21:39 | <SimonSapin> | and they say "python stdlib is where modules go to die" |
| 21:39 | <SimonSapin> | with multi-year update cycles |
| 21:39 | <SimonSapin> | not great for a living standard |
| 21:39 | <annevk> | oh |
| 21:40 | <annevk> | sounds like web standards getting implemented by browsers |
| 21:40 | <annevk> | except given that Python is kinda centralized, that's not too great |
| 21:40 | <SimonSapin> | some modules like json are great in the stdlib once they are basically "done", but most are better of outside of the stdlib |
| 21:40 | <SimonSapin> | s/better of/better off/ |
| 21:42 | <SimonSapin> | plus, a good part of the ecosystem is stuck on python 2.7 because they have dependencies not ported to py3 yet; and 2.8 is not gonna happen |
| 21:44 | <SimonSapin> | annevk: anyway, yes http://packages.python.org/encoding/ is available but I’m still not convinced this is useful outside of the web |
| 21:44 | <Hixie> | is the iana charset registry useful outside the web? |
| 21:45 | <SimonSapin> | no idea. http://docs.python.org/2/library/codecs.html#standard-encodings does not refer to anything |
| 21:46 | <zewt> | is the iana charset registry useful on the web? heh |
| 21:52 | <SimonSapin> | Release time. I can always rename later. |
| 21:53 | <Hixie> | annevk: dude, supporting <th> in first <tr> is a huge pain |
| 21:53 | <annevk> | :-( |
| 21:53 | <Hixie> | annevk: you sure you can't be bothered to put in 14 characters in your sortable tables? |
| 21:54 | <Hixie> | (have to support things like figuring out rowspans in the first <tr> of the first <tbody> then sorting the cells after that tbody, etc |
| 21:54 | <Hixie> | ) |
| 21:54 | Hixie | continues to try to make it work |
| 21:55 | <annevk> | Hixie: shouldn't that row have the same restrictions as the row in <thead>? |
| 21:56 | <Hixie> | in <thead> it's easy because i just skip the whole <thead> |
| 21:56 | <annevk> | hmm I guess not |
| 21:56 | <Hixie> | without worrying about rowspans :-) |
| 21:56 | <annevk> | yeah |
| 21:56 | <annevk> | adding <thead>/<tbody> is not too hard, it just seems like a weird requirement |
| 21:57 | <annevk> | not quite as intuitive as <table sortable> makes you believe, so to say |
| 21:57 | <Hixie> | i'll make it work |
| 21:57 | <Hixie> | it's just a pain :-) |
| 21:57 | <SimonSapin> | could you have <thead> and omit <tbody>? |
| 21:58 | <Hixie> | yes, though in practice <tbody> is implied when <thead> ends in text/html so that doesn't make much difference |
| 21:58 | <Hixie> | actually it's one more character to do that (<thead></thead> vs <thead><tbody>) |
| 21:59 | <annevk> | will somebody please think of the characters! |
| 22:00 | <SimonSapin> | oh, I’m still not used to having that much stuff close implicitly |
| 22:02 | <SimonSapin> | there is a fine line between omitting optional stuff because you know the details of the parsing algorithm, and throwing tag soup at the wall and seeing what sticks |
| 22:04 | <SimonSapin> | I’m comfortable with `display: table-cell`, but only since I implemented the algorithm that generates the related anonymous boxes |
| 22:06 | <annevk> | It seems the GitHub - Twitter bridge is broken |
| 22:06 | <annevk> | even though GitHub reports it as working :/ |
| 22:10 | <Hixie> | k, think i got it |
| 22:11 | <Hixie> | also added support for ignoring rows with just <th>s |
| 22:11 | <Hixie> | at the top of row groups |
| 22:11 | <Hixie> | as in the big input thing |
| 22:16 | <annevk> | btw, did you come across any tables that wanted their rows sorted? not that I think we should support that, just curious |
| 22:16 | <annevk> | euh, columns sorted, doh |
| 22:16 | <Hixie> | i have not heard any desire to do that from anyone except people like you and tab asking me if i should support it :-) |
| 22:18 | annevk | hides in his ivory tower |
| 22:39 | <zewt> | wow, whoever's been messing with the address bar in opera doesn't really "get" it |
| 22:39 | <zewt> | seems like it basically hides everything but the host and path, as if they've confused the address bar with the title bar |