| 03:57 | <zcorpan> | mathiasbynens: www.w3c-test.org:82/html/infrastructure/urls/resolving-urls/query-encoding/ |
| 03:57 | <zcorpan> | mathiasbynens: www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#resolve-a-url |
| 04:03 | <zcorpan> | mathiasbynens: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822 |
| 09:33 | <annevk> | working with foolip is the best <3 |
| 09:45 | <MikeSmith> | hsivonen: Can you remind me of there's a reason were sticking with the old version of jetty we're using for the validator |
| 09:46 | <foolip> | annevk: I love you dearly too, taking a look at the changes now :) |
| 09:46 | <MikeSmith> | hsivonen: I ask because, I think the version were using is not even getting security updates any longer |
| 09:46 | <foolip> | or after lunch, *poof* |
| 10:22 | <zcorpan_> | i wonder what the state of <legend> is these days |
| 10:24 | <zcorpan_> | looks like display:block doesn't work in blink at least |
| 10:25 | <zcorpan_> | <li><p>The <code>figure</code> element now uses a new element |
| 10:25 | <zcorpan_> | <code>figcaption</code> rather than <code>legend</code> because people |
| 10:25 | <zcorpan_> | want to use HTML long before it reaches W3C Recommendation.</li> |
| 10:35 | <MikeSmith> | zcorpan_: what is expected to ever change with the state of legend? |
| 10:48 | <zcorpan_> | MikeSmith: to be stylable like a normal element |
| 10:49 | <zcorpan_> | MikeSmith: at least when not in a fieldset |
| 10:50 | <zcorpan_> | MikeSmith: and follow http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-fieldset-and-legend-elements when it is |
| 10:51 | <MikeSmith> | Ah ok |
| 10:52 | <zcorpan_> | so it seems we still can't reuse <legend> for a new element |
| 10:53 | <zcorpan_> | and it will probably continue to be P5 because nobody cares about future elements not being able to reuse <legend> |
| 12:58 | <zcorpan_> | MikeSmith: i've updated http://platform.html5.org/history/ |
| 13:01 | MikeSmith | looks |
| 13:02 | <MikeSmith> | excellemente |
| 13:03 | <MikeSmith> | zcorpan_: nice updates |
| 13:04 | <MikeSmith> | hmm the e.g., http://html5.org/r/1115-1153 stuff doesn't work any more |
| 13:04 | <zcorpan_> | thx. i didn't include new copies of the spec though |
| 13:04 | <zcorpan_> | yeah |
| 13:04 | <MikeSmith> | yeah I don't think we need new copies |
| 13:12 | <annevk> | MikeSmith: sorry, didn't realize anyone was using those links |
| 13:12 | <MikeSmith> | no worries, not sure we really needed them |
| 13:13 | <annevk> | SimonSapin: any updates on the IPv4 stuff? |
| 13:16 | <SimonSapin> | annevk: not really |
| 13:17 | <annevk> | SimonSapin: is Rust attempting to solve this somehow? |
| 13:19 | <SimonSapin> | annevk: when you open a socket with a string for the host Rust’s standard library parses IPv4 and IPv6 addresses, and for things that it considers neither uses the system’s thing for resolving names, which in turn also attempts to parse IPv4 and IPv6 addresses but depending on the system may or may not support exotic v4 formats |
| 13:20 | <annevk> | good times |
| 13:20 | <SimonSapin> | I looked into various POSIX APIs, it seems hard to force a DNS query and bypass the address parsing |
| 13:21 | <SimonSapin> | unless you’re willing to implement DNS yourself, I guess |
| 13:21 | <foolip> | annevk: not sure if I stumbled onto a bigger problem in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26673 |
| 13:22 | <annevk> | foolip: not really sure how to solve it yet |
| 13:22 | <annevk> | SimonSapin: sigh |
| 13:24 | <foolip> | annevk: I think the bigger risk is getting some detached documents with non-empty fullscreen elements stacks, more than spurious fullscreenchange |
| 13:24 | <SimonSapin> | annevk: in any case, I don’t know what’s the right thing to do. There’s a couple of 6 years-old Mozilla bugs about this where people disagree with each other |
| 13:25 | <annevk> | SimonSapin: pointers? |
| 13:25 | <SimonSapin> | https://github.com/w3c/web-platform-tests/issues/1104#issuecomment-48917917 |
| 13:27 | <erlehmann> | annevk fug, why you break links :( |
| 13:27 | <erlehmann> | ._. |
| 13:27 | <erlehmann> | i certainly used one revision link in a blog post |
| 13:28 | <erlehmann> | i don't remember which one |
| 13:28 | <erlehmann> | i should make a private wayback machine |
| 13:28 | <erlehmann> | link rot is becoming too much |
| 13:28 | <annevk> | erlehmann: I need some context |
| 13:28 | <erlehmann> | <MikeSmith> hmm the e.g., http://html5.org/r/1115-1153 stuff doesn't work any more |
| 13:29 | <erlehmann> | <annevk> MikeSmith: sorry, didn't realize anyone was using those links |
| 13:29 | <erlehmann> | maybe |
| 13:29 | <annevk> | erlehmann: ah, right |
| 13:29 | <erlehmann> | annevk i assumed you broke it. |
| 13:29 | <erlehmann> | was it someone else? |
| 13:29 | <erlehmann> | i need to fight link rot. hmm. |
| 13:29 | <foolip> | erlehmann: you don't need a private one, there's "Save Page Now" on http://archive.org/web/ |
| 13:30 | <annevk> | erlehmann: all that broke was a sequence of revisions as the tool no longer supports that |
| 13:30 | <erlehmann> | annevk so links to revisions still work? |
| 13:30 | <annevk> | erlehmann: yes |
| 13:30 | <erlehmann> | i think i linked to revisions. |
| 13:30 | <erlehmann> | i am relieved |
| 13:30 | <annevk> | erlehmann: e.g. http://html5.org/r/1115 |
| 13:30 | <erlehmann> | ☺ |
| 13:30 | <foolip> | linking to a range of revisions doesn't seem useful unless Hixie happened to work on exactly one thing for a long time |
| 13:30 | <annevk> | erlehmann: the hyphen thing was a special feature, not really recommended |
| 13:31 | <erlehmann> | it conflated items into a collection |
| 13:31 | <erlehmann> | interesting |
| 13:31 | <annevk> | foolip: yup |
| 13:31 | <erlehmann> | does any one of you have a plain text blogging system and can link me to it? i want to add multimedia to http://news.dieweltistgarnichtso.net and have no idea about file structure |
| 13:32 | <zewt> | .plan? heh |
| 13:32 | <erlehmann> | s/plain text/filesystem backed/g |
| 13:33 | <erlehmann> | zewt i use single level git repositories with html files in it. hipster news 2 generates feed and overview. |
| 13:34 | <zewt> | grr, now firefox is randomly (Not Responding) and i can't tell why |
| 13:34 | <annevk> | foolip: so for fullscreen.spec.whatwg.org/#dom-document-exitfullscreen you basically want that during the iteration to dispatch the events we check if the situation with regards to the amount of elements on the fullscreen element stack has changed? |
| 13:35 | <annevk> | foolip: and if it has changed, we fully exit fullscreen? |
| 13:59 | <MikeSmith> | foolip: liking to a range of revisions is probably also useful if you're trying to document what things changed during a certain period of time -- which is exactly what http://platform.html5.org/history/ is for. But I guess that's a corner case that not many other people would want to do |
| 13:59 | <MikeSmith> | regardless, I think we could reconstruct it with links to the github html-mirror change history instead |
| 14:00 | <MikeSmith> | if we really wanted to |
| 14:01 | <MikeSmith> | (that is, construct alternative links to replace the ones we had in http://platform.html5.org/history/ to the html5.org generated changelogs that we removed after they broke) |
| 14:05 | <zcorpan_> | MikeSmith: might be more useful to have individual links to commits instead of month or year-long range of commits |
| 14:06 | <wanderview> | JakeA: do you have a sense of how close we are to updating the spec language for the expected Cache/CacheStorage changes? |
| 14:08 | <MikeSmith> | zcorpan_: yeah that would definitely be a lot more useful |
| 14:09 | <JakeA> | wanderview: We're unblocked on streams stuff, just need to get consensus on the API. I'm getting a talk together for jsconf so that's got my focus. I'll see if slightlyoff is free to take over dragging that to consensus for the next couple of weeks. |
| 14:09 | <JakeA> | Don't want to hold up the process, it's been held up enough |
| 14:10 | <wanderview> | JakeA: ah, ok... thanks for the update... I think I will implement mostly whats currently spec'd with an eye towards the expected changes then |
| 14:11 | <JakeA> | wanderview: I don't expect the querying stuff to change, just .add vs .addAll, .delete vs .deleteAll |
| 14:11 | <wanderview> | I guess i thought there was more consensus on the rest of the spec changes, but I probably skimmed some bits in the thread |
| 14:12 | <wanderview> | JakeA: great, thanks... good luck with the jsconf talk! |
| 14:50 | <annevk> | JakeA: wanderview: I thought we had consensus on the API? |
| 14:50 | <annevk> | JakeA: wanderview: short method names directly on Response/Request, plus a bodyUsed property |
| 14:50 | <JakeA> | annevk: Talking about the cache API |
| 14:51 | <annevk> | JakeA: wanderview: I guess my plan was to make that change today, might have to wait a bit |
| 14:51 | <wanderview> | annevk: I think JakeA was saying other cache API questions beyond the streams issue |
| 14:51 | <JakeA> | annevk: I'm happy with the Request/Response stuff |
| 14:51 | <annevk> | ok, that's what I get for only reading part of your exchange |
| 15:10 | <JakeA> | wanderview: What's the story around debugging serviceworker in Firefox? |
| 15:11 | <wanderview> | JakeA: currently not great as far as I know... I believe work is in progress to allow debugging workers at all :-\ |
| 15:11 | <wanderview> | let me see if I can find the bug number |
| 15:11 | <wanderview> | https://bugzilla.mozilla.org/show_bug.cgi?id=1003097 |
| 15:12 | <wanderview> | JakeA: and here is our bug to support ServiceWorkers in devtools: https://bugzilla.mozilla.org/show_bug.cgi?id=943220 |
| 15:14 | <wanderview> | JakeA: asking what the plans/timeline for that work is... we definitely want to support it |
| 15:15 | <JakeA> | wanderview: Cool! Making sure I represent the state-of-things correctly in this jsconf talk. Is there any way to get console logs out of a SW in the interim? |
| 15:15 | <wanderview> | JakeA: console.log is supported in gecko workers, yes |
| 15:15 | <JakeA> | wanderview: Where is it exposed? |
| 15:16 | <wanderview> | JakeA: uh... I think self... let me check |
| 15:20 | <smaug____> | JakeA: type console.log(123) to the first textarea. http://mozilla.pettay.fi/workerconsole/ |
| 15:20 | <smaug____> | the code will be executed in a worker |
| 15:20 | <smaug____> | and log goes to browser console |
| 15:21 | <smaug____> | (ctrl+shift+k) |
| 15:21 | <smaug____> | s/browser/web/ |
| 15:22 | <wanderview> | smaug____: thanks! I was trying to verify in my mochitest, but I guess we suppress console.log there |
| 15:23 | wanderview | bookmarks smaug's workerconsole... |
| 15:23 | <JakeA> | Wonder if that works for serviceworker (since they don't have an owner window) |
| 15:23 | <smaug____> | ah, no idea |
| 15:23 | smaug____ | knows next to nothing about service workers |
| 15:24 | <smaug____> | hmm, Blink has odd console object |
| 15:24 | <smaug____> | [object WorkerConsole] |
| 15:25 | <wanderview> | JakeA: hmm, thats a good point... I was actually assuming it would work since SW's extend workers |
| 15:27 | <wanderview> | JakeA: yea, baku confirms that console.log() won't work from a SW because of the missing window... sorry for my confusion |
| 15:28 | <annevk> | wanderview: want to file a bug on that? |
| 15:28 | <annevk> | wanderview: no debugging would be a major pita |
| 15:28 | <wanderview> | annevk: baku is doing that now |
| 15:28 | <wanderview> | I agree |
| 15:28 | <annevk> | yay |
| 15:28 | <JakeA> | wanderview: No worries! Is there any way to get those logs in the meantime, even if they go down to the command line? |
| 15:30 | <Ms2ger> | dump()? |
| 15:30 | <Ms2ger> | Probably not |
| 15:32 | <wanderview> | JakeA: can I get back to you tomorrow? I feel like we need to get our plan straight on this... when is your talk? |
| 15:33 | <JakeA> | wanderview: in two week, so no major rush. Want to get as many demos working in Firefox as possible though |
| 15:34 | <zewt> | could you proxy through a shared worker as a workaround? |
| 15:34 | <wanderview> | JakeA: ok, thanks! |
| 15:36 | <JakeA> | zewt: I think shared workers have the same issue. Could send stuff back to the page via a message port, I think that's landing soon in Firefox |
| 15:36 | <zewt> | right, you'd have to open the shared worker from a real document to receive them |
| 15:36 | <JakeA> | wanderview: will update https://jakearchibald.github.io/isserviceworkerready/ in time for the talk too |
| 15:39 | <wanderview> | JakeA: thanks... we have an internal meeting tomorrow morning... going to discuss it there |
| 15:42 | <JakeA> | zewt: good idea |
| 15:46 | <zewt> | i'd think that "service workers" would just be a type of shared worker, so you could connect to them like any shared worker |
| 15:47 | <zewt> | like a shared worker url that the browser also knows how to start up on its own |
| 16:10 | <dvorapa> | Hello! Is there anybody, who could I speak to? |
| 16:12 | <dvorapa> | Could I ask about my new meta extension? |
| 16:12 | <Ms2ger> | You can |
| 16:14 | <dvorapa> | I want to propose meta extension with keyword `version` |
| 16:14 | <dvorapa> | Specification: https://github.com/dvorapa/meta-version |
| 16:18 | <annevk> | dvorapa: if you're asking for a wiki account I need your desired username and email |
| 16:18 | <dvorapa> | Okay,username: dvorapa |
| 16:18 | <dvorapa> | email: dvorapa⊙sc |
| 16:19 | <annevk> | dvorapa: "A randomly generated password for Dvorapa has been sent to dvorapa⊙sc It can be changed on the change password page upon logging in." |
| 16:21 | <dvorapa> | annevk: Thank you. |
| 17:37 | <Domenic> | marcosc_: why does everyone want these separate WakeLock objects... why do we need to be more programmer-footgun-protective than native platforms are. |
| 17:38 | <jgraham> | People have different expectations from browsing to a website vs running a native app? |
| 17:39 | <Domenic> | this isn't even on that level |
| 17:39 | <Domenic> | it's "what if multiple pieces of code within the same website want a wake lock" |
| 17:39 | <Domenic> | in native apps they all coordinate to share a per-app lock; if different parts of the code need to coordinate, then they write code to do so |
| 17:40 | <Domenic> | whereas sicking and others think it's important that different parts of the code each get their own lock |
| 17:42 | <sicking> | Domenic: i don't feel strongly. But the editors claim that they care about that use case, but the proposed API doesn't support it |
| 17:42 | <Domenic> | oh, did not realize... |
| 17:44 | <sicking> | but it does seem like unless we specify a standard for how to do this coordination, then the JS world will have to come up with their own standard for it. And not just one standard per library, but rather one "the" standard |
| 17:44 | <sicking> | mmmm.. |
| 17:45 | <sicking> | maybe it could work for everyone to do their own solution, if that solution is based on callbacks to the embedder |
| 17:45 | <sicking> | either way, it's a relatively small difference in API complexity |
| 17:46 | <sicking> | either "screen wakelock" is a property on the document, or you can instantiate it using "new" |
| 17:47 | <sicking> | in both solutions the actual API on the lock will be the same |
| 17:54 | <Hixie> | can someone work out what Axel means in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26669 and add a clarifying comment on the bug? |
| 18:09 | <Domenic> | not "the" standard, just, if you want to use libraries that use wakelocks, they have to communicate that somehow |
| 18:11 | <Hixie> | anyone have a better term for "media source object" that has neither the words "media source", "media stream", "file", "media resource", "media data", or "blob" in it? |
| 18:11 | <Hixie> | (meaning something that is either a MediaSource, MediaStream, File, or Blob) |
| 18:11 | <Hixie> | maybe "media provider object" |
| 18:13 | <SamB__> | too bad interfaces aren't a thing |
| 18:13 | <Hixie> | even if it was an interface it'd still need a name :-) |
| 18:13 | <SamB__> | or I guess those don't actually all implement the same interface anyway |
| 18:14 | <jgraham> | Hixie: I guess he's saying something like <form autofocus="foo"><input id="foo"> would have been a better model |
| 18:14 | <jgraham> | But that's a guess |
| 18:15 | <SamB__> | jgraham: certainly less questions about how to resolve conflicts than with autofocus=yes on individual elements |
| 18:16 | <jgraham> | SamB__: Arguably an equivalent number of questions <form autofocus=foo><input id=foo><input id=foo> |
| 18:17 | <Hixie> | not to mention <form autofocus=foo></form><form autofocus=bar></form><input id=foo><input id=bar> |
| 18:17 | <Hixie> | jgraham: thanks. commented on the bug. |
| 18:17 | <SamB__> | jgraham: That question is nothing new, though |
| 18:18 | <SamB__> | Hixie: hmm, okay, that's a better example ;-) |
| 18:23 | <Hixie> | ("not to mention" is such a dumb phrase) |
| 18:26 | <tantek> | not to mention "to be honest" |
| 18:37 | <hsivonen> | MikeSmith: the reason to use an old version of Jetty is that I haven't had the time to update Jetty |
| 18:37 | <hsivonen> | MikeSmith: we should keep updating Jetty |
| 18:37 | <hsivonen> | MikeSmith: fortunately, the security bugs *usually* don't affect the way we use Jetty |
| 18:51 | <Hixie> | tantek: "to be honest" is slightly better in that it implies that one might have tried to conceal or sugar coat the statement but has decided not to |
| 18:52 | <tantek> | Hixie, good point. I often hear "not to mention" abbreviated these days in speech as "Sooooo… " preceding a statement. |
| 18:52 | <Hixie> | heh |
| 18:53 | <SamB__> | I guess "not to mention" only makes sense when followed by one or more classes of things that you aren't listing individually |
| 21:48 | <JonathanNeal> | Hey https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/07v_yMErc_A/WcyKGN1A2y0J |
| 21:48 | <JonathanNeal> | Nice! |
| 21:49 | <caitp> | eh, wouldn't get your hopes up |
| 21:50 | <caitp> | the two replies so far seem pretty conservative about adding it to the platform as a native feature, and probably not even blink-in-js. But, it would be fun to work on, so here's hopin :3 |
| 21:52 | <jsbell> | caitp: If you're thinking blink-in-js, then start with a polyfill. |
| 21:52 | <JonathanNeal> | blink in js? |
| 21:52 | <jsbell> | JonathanNeal: Implementing bits of blink in JS. |
| 21:53 | <caitp> | it might come to that, but the features I've implemented so far have been smaller in C++ than the mix of C++ boilerplate + private scripts |
| 21:53 | <jsbell> | e.g. lets say we didn't have 'window.atob()'; take a polyfill, ship it with the browser, but with appropriate security sprinkles. |
| 21:54 | <JonathanNeal> | oh you mean like a browser extension? |
| 21:55 | <jsbell> | JonathanNeal: "like" as in: same security concerns for JS code needing to run in what we call isolated worlds. But from a browser user's perspective it's a feature that ships with the browser and happens to be implemented in C++ rather than JS |
| 21:56 | <jsbell> | https://docs.google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/edit#slide=id.g3840fe06e_00 |
| 21:56 | <caitp> | I think, if we do end up getting it to support custom data and custom sort predicates, then a Blink-in-JS implementation is essentially impossible :( |
| 21:56 | <caitp> | because of those security concerns |
| 21:58 | <Hixie> | custom sort predicates? |
| 21:58 | <Hixie> | (custom data is already in the spec) |
| 21:58 | <erlehmann> | JonathanNeal how is your polyfill going? :) |
| 21:59 | <JonathanNeal> | erlehmann: Further than when last I talked about it in here. When I have free time next, I would like to start adding the more complex sorting algorithms. |
| 22:00 | <JonathanNeal> | erlehmann: http://sandbox.thewikies.com/table-sorting/ is up to date |
| 22:01 | <caitp> | Hixie: similar to Array.prototype.sort |
| 22:01 | <caitp> | letting the script assign a callback to the column header telling it how to sort its keys |
| 22:02 | <caitp> | er, sort its data |
| 22:02 | <Hixie> | caitp: i don't see how that could work. see the e-mails i sent at the time for a discussion of why. |
| 22:02 | <erlehmann> | JonathanNeal date sorting could be interesting |
| 22:02 | <Hixie> | (but basically, it's because the first callback could cause a navigation, move the table to another document, put each <td> in a different iframe, and who the heck knows what else) |
| 22:03 | <caitp> | sure it could, but who cares |
| 22:03 | <caitp> | if a user wants to break their own site, what of it :p |
| 22:03 | <Hixie> | it's not about breaking the site |
| 22:04 | <Hixie> | it's about breaking the browser |
| 22:06 | <caitp> | also I'm not sure the <data value="someString"> really counts as custom data, it's a custom string |
| 22:06 | <caitp> | it's not as flexible as say, a JSObject |
| 22:06 | <Hixie> | how would you sort a JS Object? |
| 22:06 | <caitp> | with a custom predicate! |
| 22:06 | <jsbell> | And before someone suggests it: evaluating a short snippet of script in a completely isolated execution context turns out to be something browsers are inefficient at, at the moment |
| 22:06 | <Hixie> | then it's a custom predicate, not custom data. |
| 22:07 | <caitp> | well I mean to do anything meaningful with it you'd need both |
| 22:07 | <Hixie> | jsbell: it also doesn't work when what you have to pass the isolated script is a pair of DOM nodes. :-) |
| 22:07 | <SamB__> | jsbell: that's no surprise |
| 22:07 | <Hixie> | caitp: you can already assign whatever you want to an element |
| 22:07 | <SamB__> | jsbell: building those contexts tends to be expensive |
| 22:07 | <Hixie> | caitp: myElement._myCustomData = {} |
| 22:07 | <Hixie> | or whateer |
| 22:08 | <caitp> | sure, but the sorting algorithm won't consider it when sorting |
| 22:08 | <jsbell> | Hixie: Yep. (But someone will suggest passing a serialization or something, which doesn't help) |
| 22:08 | <Hixie> | caitp: you already said you need a custom predicate |
| 22:08 | <jsbell> | SamB__: Yep. We'd like that for e.g. custom indexers in Indexed DB, but the engines aren't optimized for it (yet) |
| 22:09 | <caitp> | I'm saying, without a custom predicate, "custom data" eg attached to a node, wouldn't be much good |
| 22:09 | <caitp> | because it wouldn't be used |
| 22:09 | <SamB__> | processes, threads, JS sandboxes ... |
| 22:09 | <jsbell> | And then there's pulling in libraries to do anything useful... anyway, non-starter right now |
| 22:09 | <SamB__> | not sure about lua though |
| 22:10 | <caitp> | yeah, the performance and security concerns of a custom predicate are valid concerns |
| 22:10 | <SamB__> | jsbell: I wonder if it would be potentially faster to recycle an existing context than to make a whole new one? |
| 22:10 | <Hixie> | caitp: that's what i said before |
| 22:10 | <caitp> | I am agreeing with you |
| 22:10 | <Hixie> | ok good. so why are we still talking about custom data |
| 22:11 | <caitp> | but at the same time, without the ability to do that, people might very well not find it worth using the feature |
| 22:11 | <caitp> | and would resort to using jQuery-plugin-foo instead |
| 22:11 | <Hixie> | the spec allows for a custom sorter for exactly this reason |
| 22:11 | <Hixie> | oh hey, good news everyone! I've figured out a way to bypass the spec's pop-up blocker... and chrome implements the spec |
| 22:13 | <caitp> | where exactly does the spec allow for a custom sorter? it must not be in the tables document of the multipage spec |
| 22:14 | <jsbell> | SamB__: Dunno. I suspect competition on speed and power vs. things like ES6 modules (and blink in JS...) will drive down the cost of contexts |
| 22:14 | <Hixie> | <table onsort="...run whatever algorithm you want to sort the table here..."> |
| 22:14 | <caitp> | oh, I see. |
| 22:14 | <Hixie> | it lets the browser handle all the "table changed" logic, "this is the sorted column" logic, etc |
| 22:14 | <Hixie> | and just fires the event when the table needs sorting |
| 22:15 | <Hixie> | there's two ways to use it, basically |
| 22:15 | <caitp> | so you're saying they would sort the table manually and then prevent default to stop the default logic |
| 22:15 | <Hixie> | you can either just actually sort the table, then return false |
| 22:15 | <Hixie> | or you can set the custom sort data to the rows in the order you want, then return true |
| 22:16 | <caitp> | I mean that could work, but that's a lot more complicated than a predicate |
| 22:17 | <caitp> | so it seems unlikely most people would use it |
| 22:17 | <Hixie> | it's actually only a very few lines more complicated |
| 22:17 | <Hixie> | probably just a matter of putting the rows in an array, sorting the array using a custom predicate, and then reappending the rows in the order you care about |
| 22:18 | <Hixie> | when you have your own function you don't have to worry about all the edge cases the algorithm normally worries about |
| 22:18 | <Hixie> | like multiple <tbody>s, or row-spanning cells, or all that nonsense |
| 22:26 | <roc> | some ability to run pure JS functions cheaply would be useful in various places in the platform |
| 22:26 | <roc> | vertex shaders for CSS filters |
| 22:27 | <roc> | various extensible layout things |
| 22:27 | <roc> | audio processing |
| 22:45 | <JonathanNeal> | I think people will demand the ability to sort tables by their own method. |
| 22:50 | <caitp> | they certainly will |
| 23:02 | <caitp> | anyway JonathanNeal I'm probably not going to get a green light on that intent-to-implement thread, but I'm happy to help work on the polyfill if you want some assistance with it |
| 23:44 | <JonathanNeal> | caitp: yes, once it’s in slightly better shape I need to put it on GitHub. |