| 00:13 | <TabAtkins> | Domenic: plinss just landed code for recognizing headings that are definitions. I'll shortly be adding the code to Bikeshed to make it work properly, too. |
| 06:06 | <annevk> | littledan: Node.js adding self first makes the most sense to me. Then we can figure out if that's worth harmonizing over. |
| 06:06 | <annevk> | TabAtkins: Fetch and I think also HTML have header definitions |
| 06:06 | <annevk> | TabAtkins: though I think HTML also has one case where a single heading contains multiple definitions (for h1, h2, etc., ironically) |
| 09:24 | <annevk> | Oh, so now the IETF approved http://tools.ietf.org/html/rfc7159 that's the only RFC defining the MIME type, but it seems they at least aligned with the definition from Ecma, although I haven't read closely... |
| 09:42 | <annevk> | philipj: does not seem to be much in https://lists.w3.org/Archives/Public/public-editing-tf/ or https://github.com/w3c/editing |
| 09:43 | philipj | sees Ryosuke Niwa, Arthur Barstow and Florian Rivoal among the posters |
| 09:43 | <annevk> | philipj: https://github.com/w3c/editing/issues/56 is the most interesting |
| 09:45 | <philipj> | I'll watch that |
| 09:46 | <philipj> | Looks like Ryosuke-san has some healthy skepticism |
| 09:48 | <annevk> | yeah |
| 10:03 | <MikeSmith> | annevk: thanks for doing the bugzilla hygiene |
| 10:07 | <annevk> | MikeSmith: made it possible to see all bugs on a single page again |
| 10:07 | <annevk> | MikeSmith: not really impressed by how Web Components folks just moved all over Template bugs without any additional triage |
| 10:08 | <annevk> | but most was spammy stuff from the widget |
| 10:15 | <MikeSmith> | annevk: yeah that Templates move was kind of quick-and-dirty |
| 10:59 | <philipj> | annevk: what do you think about forking https://github.com/ayg/editing to https://github.com/whatwg/editing now that https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html is gone? |
| 11:00 | <annevk> | philipj: we should ask ayg if he would be willing to move the repository |
| 11:01 | <philipj> | yeah, there's certainly no rush |
| 11:01 | <annevk> | philipj: and maybe we should include rniwa/ehsan in that email to get a feeling for what everyone else feels |
| 11:02 | <annevk> | well "everyone" |
| 11:02 | <annevk> | at least those that did some work on this in the past |
| 11:02 | <annevk> | overall though I'd be supportive of that, certainly if this new Editing TF is not actually doing any hard work |
| 11:03 | <philipj> | well perhaps they are doing good work, but just not taking ownership of execCommand() |
| 11:06 | <annevk> | or contenteditable... |
| 11:07 | <annevk> | or designMode |
| 11:07 | <annevk> | if you don't take ownership of the primitives that exist, you're bound to create a shit show |
| 11:36 | <annevk> | Speaking of editing, https://www.indiegogo.com/projects/prosemirror/ is pretty interesting |
| 11:36 | <annevk> | philipj: it seems ayg is still around |
| 11:37 | <philipj> | annevk: yep, and with no love for execCommand() :) |
| 11:38 | <annevk> | yeah, I wonder what his answer is to "what about Servo?" |
| 11:38 | <JoWie> | i remember creating a rich text editor using javascript & dom many years ago, without using execCommand. that sure was a lot of work |
| 11:38 | <annevk> | I'm assuming Edge simply has IE's old code without all the ridiculous switch statements |
| 11:39 | <philipj> | annevk: he already answered in https://github.com/w3c/clipboard-apis/issues/16#issuecomment-127570472 |
| 11:40 | <annevk> | ah I see |
| 11:44 | <JoWie> | it would be great if the editing api was more low level |
| 11:44 | <philipj> | a sane API which execCommand can be built on top of would be nice |
| 11:45 | <JoWie> | contenteditable is so incredibly buggy in all browsers |
| 11:45 | <JoWie> | (not just execCommand) |
| 11:46 | <JoWie> | for example, in certain situations elements can "leak" outside of the element that has contenteditable |
| 11:47 | <JoWie> | so i think the behaviour of contenteditable must either be very well defined, or provide a much lower level api |
| 12:03 | <GPHemsley> | annevk, MikeSmith: What am I supposed to be migrating? |
| 12:04 | <annevk> | GPHemsley: the idea is to slowly move over to GitHub |
| 12:04 | <GPHemsley> | :( |
| 12:04 | <annevk> | GPHemsley: as you can see in e.g., URL and DOM |
| 12:04 | GPHemsley | dislike GitHub issues |
| 12:05 | GPHemsley | are plural |
| 12:05 | <GPHemsley> | annevk: I assume there's justification for this? |
| 12:07 | <annevk> | GPHemsley: I don't have a long form argument handy |
| 12:08 | <GPHemsley> | I noticed also that the editor has been removed from the header? |
| 12:08 | <annevk> | GPHemsley: in general we notice more participation on GitHub and due to GitHub's tight integration of PRs, issues, and commits, it also makes things easier to track |
| 12:09 | <annevk> | GPHemsley: yes, we did that because some people felt having a name there might be unwelcoming to contributions of others, there's some other arguments too |
| 12:09 | <GPHemsley> | hmm |
| 12:10 | <annevk> | GPHemsley: if specifications are more community owned, it doesn't make much sense to have a single name at the top |
| 12:10 | <GPHemsley> | are all of our specs by definition community-owned? |
| 12:10 | <MikeSmith> | it makes even less sense to list 10+ names at the top the way some W3C specs do |
| 12:11 | <MikeSmith> | IMHO name(s)-at-the-top-of-the-spec often creates perverse incentivies |
| 12:11 | <GPHemsley> | interesting |
| 12:12 | <MikeSmith> | GPHemsley: what else would they be if not community-owned? |
| 12:12 | <annevk> | GPHemsley: they are in the public domain |
| 12:12 | <annevk> | GPHemsley: and maintained by the WHATWG |
| 12:12 | <GPHemsley> | I always saw it as "who's the expert on this spec?" or "who do I talk to to clarify what this spec means?" |
| 12:12 | <annevk> | dunno how other folks do it |
| 12:12 | <GPHemsley> | MikeSmith, annevk: That sounds like by definition, then |
| 12:13 | <annevk> | GPHemsley: it would actually be a bad thing if it encouraged that kind of line of reasoning |
| 12:13 | <GPHemsley> | k |
| 12:13 | <MikeSmith> | GPHemsley: what you describe is what the Participate links are for, really |
| 12:13 | <annevk> | GPHemsley: although it's great to have a couple of people own the spec and sort through things, having all conversations flow through that group alone seems damaging long term |
| 12:14 | <GPHemsley> | Well, in that case, then, I guess... patches welcome ;) |
| 12:14 | <annevk> | MikeSmith: yeah, in the W3C you often have people volunteer to have their name on the spec, and only for that... |
| 12:14 | <MikeSmith> | annevk: yep |
| 12:14 | <GPHemsley> | although I appear to have turned github issues off for mimesniff |
| 12:14 | <annevk> | GPHemsley: I'm happy to make the changes I made elsewhere at some point directly if you don't mind |
| 12:15 | <GPHemsley> | it looks like you can still do pull requests even with issues turned off |
| 12:15 | <MikeSmith> | the fringe WGs in the Linked-Data/Semantic-Web area are full of that "I'm here to get my name on a spec"-think |
| 12:15 | <GPHemsley> | they're also specs that few people look at, so... *shrug* |
| 12:16 | <MikeSmith> | annevk: re "having all conversations flow through that group alone seems damaging long term", yeah, hypothetically speaking |
| 12:17 | <MikeSmith> | annevk: hypothetically speaking, if an active editor were to sorta to go away and do other things for 10 months or whatever, on a spec that's never really been a community product in the same way most of our other ones now are |
| 12:17 | <MikeSmith> | just sayin' |
| 12:17 | <MikeSmith> | that would be less than ideal, if that were to ever happen |
| 12:18 | <MikeSmith> | especially if it were to happen with a really important spec |
| 12:18 | <MikeSmith> | so let's just hope that never happens I guess |
| 12:19 | <annevk> | MikeSmith: indeed :-) |
| 12:23 | <Ms2ger> | Let's hope such a spec would at least have an open-source publication pipeline |
| 12:23 | <GPHemsley> | I haven't migrated off anolis yet, either |
| 12:29 | <jgraham> | If Hixie is actually blocking any work then it seems possible to address the situation |
| 13:18 | <philipj> | annevk for execCommand editor, wee :) |
| 13:19 | <annevk> | philipj: "maintainer" |
| 13:19 | <annevk> | "PRs appreciated" |
| 13:19 | <annevk> | If Aryeh is indeed giving up... |
| 13:20 | <philipj> | I think he definitely isn't interested in editing, he said as much when I asked about the spec in an email a few years ago |
| 13:52 | <annevk> | philipj: your list seems about right |
| 13:52 | <annevk> | philipj: I think Domenic is only interested in elements and attributes, but I guess we might as well make it complete |
| 13:52 | <annevk> | philipj: and yeah, breaking invariants elsewhere was my worry too |
| 13:53 | <annevk> | philipj: to avoid that you need to go with the HTML/XML union |
| 13:54 | <MikeSmith> | nice to see Aryeh back around some, the last few days |
| 13:55 | <philipj> | annevk: yeah, that should at least reduce the risk, even if it's still the case that there are things that can't be roundtripped in XML and/or HTML |
| 13:55 | <annevk> | yeah, whoever designed that... |
| 13:56 | <philipj> | Domenic: maybe you can just add use counters for the things you'd like and I can sit back and do nothing? :) |
| 13:56 | <Domenic> | still catching up on the morning email... |
| 13:56 | <philipj> | annevk: any idea what the union would look like, is it just a short blacklist for the first code point and another short blacklist for the rest, or something more complicated? |
| 13:57 | <annevk> | philipj: more complicated |
| 13:57 | <annevk> | philipj: you need to validate against XML, if that fails, validate against HTML, if that fails, throw |
| 13:57 | <annevk> | philipj: if at any point you succeed you have a winning name |
| 13:58 | <philipj> | so more exception handling code in some of the most most called methods there are... |
| 13:58 | <annevk> | yeah, seems unlikely |
| 13:58 | <annevk> | although you could code it more efficiently that that of course |
| 13:58 | <annevk> | by branching |
| 13:58 | <philipj> | it might not affect perf at all since it's in an unlikely branch, but still not great |
| 13:58 | <philipj> | so let's just wait for Domenic to read some more email :) |
| 13:59 | <annevk> | although apparently it's more efficient to create a bunch of elements through appending to DocumentFragment and then cloning that then invoking createElement() a whole lot |
| 14:00 | <philipj> | well, yeah, at some point the overhead of bindings just ruins everything I guess |
| 14:00 | <annevk> | yeah I guess so |
| 14:00 | <philipj> | maybe we should have API that allow you to create lots of elements in a single call, without parsing? |
| 14:02 | <annevk> | probably not |
| 14:02 | <annevk> | WebAssembly can also take some of this away I'm told |
| 14:03 | Domenic | eyerolls at the wasm panacea |
| 14:03 | <Domenic> | just allowing everything sounds better |
| 14:03 | <Domenic> | what would the use counter do? |
| 14:07 | <philipj> | Domenic: I was thinking measure how often an exception is thrown where it no longer would be, but I'm not sure what to do with the result if it's anything but ~0.001% |
| 14:07 | <philipj> | 0.1% could mean that we'll now make 0.1% of pages work better, who knows |
| 14:07 | <Domenic> | hmm yeah i would be surprised if it is >0% though, so that seems like a reasonable thing |
| 14:08 | <philipj> | depending on exceptions being thrown is unusual, but given a common enough API it enters the realm of the possible |
| 14:09 | <philipj> | But I dunno, just trying it would answer the question much faster :) |
| 14:10 | <annevk> | zcorpan wanted to do this at some point btw |
| 14:10 | <philipj> | o_O is TimBL actually posting on blink-dev as 0123456789abcedf⊙gc ? |
| 14:10 | <annevk> | I'm not sure why he didn't |
| 14:10 | <annevk> | philipj: I didn't see that |
| 14:10 | <philipj> | annevk: in the <keygren> thread |
| 14:11 | <philipj> | It's his picture and name, but could just as well be an impostor I guess |
| 14:11 | <Ms2ger> | That sounds quite unlikely |
| 14:12 | <annevk> | I think that's him |
| 14:13 | <philipj> | Odd |
| 14:20 | <wanderview> | Domenic: what does this mean? https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0232.html |
| 14:21 | <annevk> | wanderview: nothing |
| 14:22 | <wanderview> | ok |
| 14:25 | <annevk> | Domenic: I do hope that if IDL is formalized we could actually have a "copy" operation that just creates a new instance and copies over all internal slots |
| 14:25 | <annevk> | Domenic: so you can just write "copy" in your spec and it means something when applied to an object |
| 14:43 | <Domenic> | annevk: maybe, such an operation is rarely useful (never used in ES) |
| 14:47 | <Domenic> | What does no-backref do? |
| 14:54 | <annevk> | Domenic: something I should probably patch into dfn.js |
| 14:55 | <annevk> | Domenic: partially because ES doesn't define structured cloning as it should |
| 14:55 | <Domenic> | True |
| 14:56 | <annevk> | There's quite a lot of objects that are copied in some manner, though arguably such a generic definition might give the wrong results for elements and such, that don't necessarily want all their internal slots copied |
| 15:13 | <annevk> | Another interesting thing, we gave up on DOM Parsing & Serialization, but the W3C stopped maintaining their copy too |
| 17:07 | <smaug____> | does github's bug tracker have anything like needinfo in bugzilla? |
| 17:08 | <wanderview> | smaug____: closest is @ mention in a comment I believe |
| 17:09 | <smaug____> | which is quite different |
| 17:09 | <wanderview> | I guess "no" then :-) |
| 17:10 | <smaug____> | wanderview: I mean, needinfos end up to a queue which you can check easily |
| 17:10 | <smaug____> | I assume @ stuff don't end up to any queue |
| 17:10 | <smaug____> | if you miss some bugmail, you really miss it |
| 17:11 | <wanderview> | smaug____: they show up here: https://github.com/notifications |
| 17:11 | <wanderview> | probably too easy to clear something from the list, though |
| 17:12 | <smaug____> | wait what? I need to read bugmail _and_ clear that list |
| 17:12 | <smaug____> | huh |
| 17:12 | <smaug____> | though, perhaps there is some pref |
| 17:14 | <wanderview> | sorry |
| 17:15 | <wanderview> | I personally ignore that notifications page... but its kind of queue like |
| 17:43 | <ajankovic> | hello, I was wondering why isn't there encoding spec for iso-8859-1 on whatwg.org? |
| 17:44 | <Domenic> | you can assign github issues and see all issues assigned to you |
| 17:44 | <Domenic> | again not quite the same |
| 17:45 | <Domenic> | ajankovic: there is. It is an alias of windows-1252. |
| 17:46 | <ajankovic> | Domenic: I saw there is an alias for it but those two are not the same? |
| 17:46 | <Domenic> | ajankovic: it turns out they are in shipping software |
| 17:47 | <Domenic> | (or there could be a bug in encoding spec, but this particular issue has the feel of something that's already been discussed a lot.) |
| 17:50 | <Domenic> | ajankovic: I think the way to show they are different would be to create a document, with <meta charset="windows-1252">, containing one of the bytes in https://encoding.spec.whatwg.org/index-windows-1252.txt, and show that it is not displayed in browsers according to that table |
| 17:51 | <Domenic> | sorry, with <meta charset="iso-8859-1"> |
| 17:55 | <ajankovic> | thanks, I was led here by the issue in Go language implementation of character conversion which uses whatwg specs to generate character conversion tables, I guess whatwg is web centric and I need better precision than that for my project |
| 17:56 | <Domenic> | ajankovic: well, interoperability with the web is the primary use case for a lot of encoding software. I would suggest interoping with the web if at all possible. |
| 17:57 | <Domenic> | ajankovic: otherwise you will interpret one of those bytes differently than web browsers do, which is a recipe for lots of bugs being filed on your software :) |
| 17:59 | <ajankovic> | Domenic: I am dealing with character conversions for sms messages |
| 18:04 | <Ms2ger> | ajankovic, I'm so sorry |
| 18:06 | <ajankovic> | Ms2ger: thank you that was my first laugh today |
| 18:06 | <jgraham> | ajankovic: And it will be your last too. |
| 18:06 | <jgraham> | Sorry. |
| 18:06 | <Domenic> | yes, all i can offer at this point are condolences. |
| 18:07 | <Ms2ger> | ajankovic, more seriously, the whatwg spec is not very likely to be useful for you |
| 18:44 | <wanderview> | JakeA: you around by any chance? |
| 19:21 | <JakeA> | wanderview: a little |
| 19:21 | <wanderview> | JakeA: I decided to write a fetch issue... I'll let annevk set me straight in the morning |
| 19:21 | <wanderview> | thanks, though |
| 19:22 | <Domenic> | TabAtkins: I don't really understand "terms defined by this specification". E.g. in https://domenic.github.io/streaming-mediastreams/#index-defined-here it says this spec defines "stream" which feels a bit ridiculous. |
| 19:23 | <TabAtkins> | Domenic: It's an argument to a method. |
| 19:23 | <Domenic> | TabAtkins: yes. Which is why saying that the definition of "stream" is that argument is pretty silly. |
| 19:23 | <Domenic> | Maybe only exported definitions should appear there? |
| 19:23 | <TabAtkins> | Arguments are exported. ^_^ |
| 19:24 | <Domenic> | O__________o |
| 19:24 | <Domenic> | can i turn that off |
| 19:24 | <TabAtkins> | Everything is exported by default except "dfn" type arguments. |
| 19:24 | <TabAtkins> | Why do you want to? |
| 19:24 | <Domenic> | now anytime someone does <a>stream</a> in a Bikeshed spec they'll get this spec's method argument!? |
| 19:25 | <Domenic> | I want method arguments to be refactorable at will, not something people take dependencies on |
| 19:25 | <JakeA> | wanderview: I was thinking again about a fetch option that causes failure on !ok |
| 19:25 | <Domenic> | method argument names, that is |
| 19:25 | <JakeA> | I got bitten by a server 500 getting cached |
| 19:25 | <TabAtkins> | No, it's pretty hard to reference an argument. Almost impossible to do accidentally. |
| 19:26 | <TabAtkins> | You have to write either {{foo()/arg}} or {{arg!!argument}} (or the equivalents in longhand). |
| 19:27 | <wanderview> | JakeA: yea... seems annoying... I imagine best practice might become to put a thing on the promise chain to turn bad status codes into a rejection |
| 19:27 | <Domenic> | i would really rather them not be there ever. if they have to be then maybe nest them under the relevant constructor or method name? My index is clogged up with argument stuff I don't care about using up all the good terms. |
| 19:27 | <TabAtkins> | Domenic: *That* is something I can do. |
| 19:28 | <TabAtkins> | Tho what do you mean by "using up all the good terms"? |
| 19:28 | <wanderview> | fwiw, here's my fetch issue: https://github.com/whatwg/fetch/issues/101 |
| 19:28 | <Domenic> | I look at the list of terms defined and I think "wow this spec defines stream, cool" |
| 19:28 | <Domenic> | I'll file an issue for nesting |
| 19:29 | <TabAtkins> | I've wanted to nest values underneath properties for a while; nesting arguments underneath their function should work the same. |
| 19:31 | <Domenic> | I still think, given that argument names don't have any normative value, they should not be defined by specs |
| 19:31 | <Domenic> | well, should not be listed as officially defined by specs |
| 19:35 | <TabAtkins> | Domenic: I've had use-cases for referring to them; given that, they need to be an anchor. But I agree that they probably shouldn't be exported by default. (That won't remove them from the index.) (Tho maybe it should.) |
| 19:36 | <Domenic> | :) yes IMO it should |
| 19:36 | <TabAtkins> | That would mean that a lot of dfn-type definitions would stop showing up, tho maybe that would be a clue for people to export them. |
| 19:39 | <Domenic> | +1 |
| 19:39 | <Domenic> | I pretty much only use <dfn>s right now when I should be exporting them a lot more |
| 19:39 | <Domenic> | I have different problems though with Web IDL vs. JS :-/ |
| 21:19 | <Domenic> | Why do we use <div class="note"> instead of <aside class="note"> in specs? |
| 22:25 | <JoWie> | smaug____: github uses tags for things like that |
| 22:25 | <TabAtkins> | Domenic: Our markup standards are a carry-over from pre-html? |
| 22:25 | <TabAtkins> | Sorry, pre html5 |
| 22:25 | <Domenic> | TabAtkins: hmm kind of what i figured, but a bit sad. |
| 22:27 | <TabAtkins> | Anyone have opinions on me auto-formatting IDL blocks like https://github.com/tabatkins/bikeshed/issues/449 suggests? |
| 22:28 | <TabAtkins> | I'm pretty sure the syntax highlighting is doable with a minimum of effort (all the structures already exist, I just need to tag them with classes and style them). |
| 22:49 | <Domenic> | TabAtkins: I object to the alignment. The coloring seems fine though. |
| 23:49 | <botie> | cvrebert, at 2015-08-02 06:51 UTC, MikeSmith said: no, the SVG reference is one thing that should not be updated. |
| 23:55 | <cvrebert> | Any w3C peeps able to look up who's a GitHub Collaborator on https://github.com/w3c/css-validator ? |