| 00:03 | <zewt> | death to target=_blank. |
| 00:09 | <SamB> | zewt: that did always seem like a dumb idea |
| 00:22 | <cabanier> | MikeSmith: I submitted a couple of webkit patches for error handling: https://bugs.webkit.org/show_bug.cgi?id=132407 and https://bugs.webkit.org/show_bug.cgi?id=132412 |
| 00:23 | <MikeSmith> | cabanier: cool |
| 00:24 | MikeSmith | takes a look |
| 00:25 | <cabanier> | MikeSmith: that should make WK turn green for 4 more tests |
| 00:28 | <MikeSmith> | cabanier: excellent |
| 00:29 | <MikeSmith> | cabanier: thanks for taking time on the testing stuff, and raising the bugs, and the patches |
| 01:14 | <Hixie> | hober: i'm not sure what that is saying :-| |
| 01:23 | <MikeSmith> | cabanier: trybots are indicating that test is still failing, right? |
| 01:28 | <MikeSmith> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25521 is a bit unsettling |
| 01:28 | <MikeSmith> | not that I disagree with the rationale |
| 01:29 | <MikeSmith> | it's just, if we end up changing the platform do the point where authors can't get any useful linting/static-checking feedback done on their markup sources, that would suck |
| 01:31 | <MikeSmith> | leading eventually to total societal breakdown |
| 01:31 | <MikeSmith> | "In accordance with prophecy" |
| 01:33 | <cabanier> | MikeSmith: yes, I missed some tests |
| 01:33 | <MikeSmith> | cabanier: ah ok |
| 01:36 | <Hixie> | MikeSmith: i have no idea what that bug is saying |
| 01:37 | <Hixie> | MikeSmith: web components aren't valid in html currently. i presume that the web components people have some sort of solution for that, e.g. via the inheritance thing (<tr is="my-fancy-tr">) |
| 01:37 | <MikeSmith> | Hixie: "For these reasons, all of these content model rules should probably be discarded entirely" it says |
| 01:37 | <eligrey> | what's the wiki syntax for external links? |
| 01:37 | <eligrey> | i need to put a period after a link and i don't want it to be included in the link |
| 01:37 | <MikeSmith> | Hixie: I think you're being generous in that assumption ;-) |
| 01:38 | <Hixie> | MikeSmith: that seems like a non-starter. I mean, we can't make <p><html> valid, it would never do anything understandable. |
| 01:38 | <MikeSmith> | eligrey: it's just metawiki syntax, I think |
| 01:38 | <MikeSmith> | eligrey: [#FooBar] or such |
| 01:38 | <eligrey> | same for extenal links? |
| 01:38 | <eligrey> | i don't edit wikipedia, sorry :p |
| 01:38 | <MikeSmith> | eligrey: oh external |
| 01:39 | <MikeSmith> | eligrey: [http://foo link text here] I think |
| 01:39 | <eligrey> | thanks |
| 01:40 | <eligrey> | the wiki markup thing gives me a list of all the different types of markup |
| 01:40 | <eligrey> | you would think hovering over each item would give me a description, but no |
| 01:40 | <eligrey> | they all say "Click on the character or tag to insert it into the edit window" |
| 01:40 | <eligrey> | so helpful :) |
| 01:40 | <eligrey> | MikeSmith: anyways thanks for that |
| 01:40 | <MikeSmith> | wikis all suck |
| 01:40 | <MikeSmith> | eligrey: np |
| 01:43 | <MikeSmith> | Hixie: yeah I guess in the proposed regime there'd still need to be a few prohibitions on markup that just would never make sense |
| 01:44 | <MikeSmith> | Hixie: but the bug seems pretty clear to meーshe's saying that the "optionally a caption element, followed by zero or more colgroup elements, followed optionally by a thead element, followed optionally by a tfoot element, followed by either zero or more tbody elements or one or more tr elements, followed optionally by a tfoot element (but there can only be one tfoot element child in total), optionally intermixed with one or more script-supporting elem |
| 01:44 | <MikeSmith> | oops |
| 01:44 | <MikeSmith> | well anyway, that part |
| 01:44 | <Hixie> | your comment cut off in the middle of the spec quote |
| 01:44 | <MikeSmith> | she's saying that's too constrained in the face of web components |
| 01:45 | <MikeSmith> | Hixie: was just quoting the spec, nothing more |
| 01:45 | <MikeSmith> | hadn't meant to quote the whole thing |
| 01:45 | <Hixie> | ah k |
| 01:45 | <Hixie> | i don't think that's right |
| 01:45 | <MikeSmith> | was going to put some ellipsis in there, since I'm pretty sure you're familiar somewhat with the part that follows |
| 01:46 | <Hixie> | i mean, sure, you'll want to allow elements to override <tr>, etc |
| 01:46 | <MikeSmith> | yeah |
| 01:46 | <Hixie> | but those elements still need to be real <tr>s at some level |
| 01:46 | <Hixie> | as in is="" |
| 01:46 | <Hixie> | or some similar solution |
| 01:48 | <MikeSmith> | yeah I guess it would help there if she could give an actually markup example |
| 01:48 | <MikeSmith> | I'll post a comment |
| 01:48 | <MikeSmith> | oh wait she did |
| 01:48 | <MikeSmith> | https://github.com/angular/angular.js/issues/7295 |
| 01:48 | MikeSmith | reads |
| 01:49 | <MikeSmith> | oh geez man |
| 01:49 | <Hixie> | that's about the parser |
| 01:49 | <Hixie> | not the content models |
| 01:49 | <MikeSmith> | yeah |
| 01:49 | <MikeSmith> | bingo |
| 01:49 | <MikeSmith> | yup |
| 01:51 | <Hixie> | it's amazing how many people confuse those two things |
| 01:51 | <Hixie> | i mean, that's not a criticism or anything |
| 01:51 | <Hixie> | i'm honestly just amazed at how confusing this apparently is |
| 01:54 | <boogyman> | so do you think there's an opportunity to rephrase and/or add additional examples to the spec |
| 01:54 | <Hixie> | there's always the opportunity to rephrase and add examples |
| 01:55 | <Hixie> | post suggestions to http://whatwg.org/newbug :-) |
| 01:55 | <boogyman> | correct, but i would say that if "this" is an issue which has confused "many people", that might bump this opportunity higher on the priority list. |
| 01:57 | <Hixie> | oh, that particular issue |
| 01:57 | <Hixie> | there's already entire sections that try to explain it |
| 01:57 | <Hixie> | i think teh confusion is mostly amongst people who haven't read the spec |
| 02:00 | <MikeSmith> | the parsing behavior is just inherently confusing |
| 02:01 | <Hixie> | yeah that too |
| 02:01 | <MikeSmith> | and even when you read the spec, you don't want to believe that's how things actually work |
| 02:01 | <Hixie> | but it's the way people assume the content models have anything to do with that which is what i'm mostly talking about |
| 02:01 | <MikeSmith> | because, how dumb would that be, for people to create something that works that way |
| 02:01 | <MikeSmith> | Hixie: yeah |
| 02:02 | <MikeSmith> | Hixie: maybe we could put some icon there |
| 02:02 | <MikeSmith> | like the fingerprinting icon |
| 02:02 | <MikeSmith> | to say, this is not a UA requirements |
| 02:03 | <MikeSmith> | I suggest this icon: https://avatars2.githubusercontent.com/u/568252?s=140 |
| 02:04 | <boogyman> | argh! stupid firefox :( crashes on the single page spec page. haha MikeSmith |
| 02:04 | <Hixie> | MikeSmith: well, that's what developers.whatwg.org is supposed to be, really |
| 02:04 | <MikeSmith> | my firefox doesn't crash on it, just takes a long time to load |
| 02:04 | <MikeSmith> | Hixie: true |
| 02:04 | <Hixie> | MikeSmith: but the problem is people assume that the authoring requirements _are_ UA requirements |
| 02:05 | <MikeSmith> | right |
| 02:05 | <Hixie> | i mean, it's UA requirements this contributor is looking for |
| 02:05 | <Hixie> | so saying "don't look here, this is for UAs" might even be what is making them look at content models |
| 02:05 | <MikeSmith> | maybe we need a version with all the authoring requirements suppressed, and just have the UA requirements |
| 02:05 | <MikeSmith> | seriously |
| 02:06 | <Hixie> | that would be... interesting |
| 02:06 | <MikeSmith> | which I realize might require marking stuff with class=author |
| 02:06 | <Hixie> | a lot of work to do though |
| 02:06 | <MikeSmith> | yeah |
| 02:06 | <MikeSmith> | I remember when you did the class=impl change |
| 02:12 | <zewt> | there's a pretty deep difference between implementation requirements and conformance criteria, the normative language that basically says "you must do this (but if you don't, everything will still work in a precisely defined way)" has always felt like a bad use of "must" to me |
| 02:13 | <zewt> | don't really know how it could be fixed... |
| 02:16 | <MikeSmith> | zewt: well the "Content model" sections don't contain any musts anyway |
| 02:16 | <MikeSmith> | or anything else normative-ish looking |
| 02:16 | <Hixie> | yeah, i just have one "must" in the definition of "content model" |
| 02:16 | <MikeSmith> | oh? |
| 02:16 | MikeSmith | wonders which |
| 02:17 | <Hixie> | "content model. A normative description of what content must be included as children and descendants of the element." |
| 02:17 | <zewt> | well, replying to authoring requirements vs. UA requirements |
| 02:17 | <Hixie> | it's actually redundant with "An HTML element must have contents that match the requirements described in the element's content model." a few paragraphs later |
| 02:27 | <MikeSmith> | Hixie: as another data point about the confusion: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25501 |
| 02:28 | <MikeSmith> | confusion about "content models" vs types of content (flow, phrasing, etc.) |
| 02:29 | <MikeSmith> | and asking that "empty" be defined as a content type |
| 02:30 | <MikeSmith> | so yeah it is confusing |
| 02:31 | <Hixie> | that's a different problem. That's the problem of people who forget the english language while reading the spec. :-P |
| 02:48 | <MikeSmith> | Hixie: not so fair, man :-) |
| 02:48 | <Hixie> | come on, that bug is basically just the guy saying he doesn't know what "empty" means |
| 02:48 | <MikeSmith> | it's kind of terms-of-art usage of English |
| 02:49 | <MikeSmith> | Hixie: yeah true in that case |
| 02:49 | <MikeSmith> | it does come down to that |
| 02:49 | <Hixie> | i guess the real problem is assuming that a word is a term of art when it's just english |
| 02:49 | <MikeSmith> | hmm yeah |
| 02:49 | <Hixie> | but i don't know what else the term would mean |
| 02:49 | <MikeSmith> | sometimes empty just means empty |
| 02:49 | <MikeSmith> | yup |
| 02:50 | <MikeSmith> | there is the void vs empty thing though |
| 02:50 | <Hixie> | well "void" doesn't mean anything clear, so assuming it's a term of art seems reasonable :-) |
| 02:50 | <MikeSmith> | which is good, and an improvement over what we had before |
| 02:50 | <MikeSmith> | sure |
| 04:09 | <Hixie> | sweet lord there's a lot of script data states |
| 04:31 | <Domenic_> | +1 for a for-UAs version of the spec, containing the actually-normative stuff. |
| 09:30 | <annevk> | Hixie: aaah, we already have listener observation of sorts with http://xhr.spec.whatwg.org/#upload-events-flag |
| 09:30 | annevk | feels bad |
| 13:52 | <zewt> | annevk: i wonder if it would be web-compat to change that to "set the upload events flag if the xhr.upload property has been accessed" |
| 13:53 | <annevk> | zewt: possible |
| 13:54 | <annevk> | There's also http://xhr.spec.whatwg.org/#garbage-collection |
| 13:54 | <zewt> | a different sort of lameness, but maybe a lesser one |
| 13:54 | <zewt> | that seems okay, i think... |
| 13:55 | <zewt> | (also a little weird that accessing .upload would mean requests complete even if you throw away the object when they wouldn't otherwise, but not catastrophic) |
| 13:55 | <zewt> | oh, you mean another event listener check. hmm |
| 13:56 | <zewt> | personally I intuitively thought that XHR would always complete the request if I let go of it, even if I wasn't listening for anything on it |
| 13:56 | <zewt> | is there a reason to not just never GC the object while the request is in the air? |
| 13:58 | <zewt> | could see interop issues there, eg. function send_keepalive() { var xhr = new XHR(); xhr.open("http://api.server.com/ping";); xhr.send(); } may or may not actually send the ping, depending on GC (if I understand correctly) |
| 13:58 | <annevk> | EventSource and WebSocket do the same; they might need it more, granted |
| 13:59 | <zewt> | makes more sense for streaming things that would never close on their own |
| 13:59 | <annevk> | Heh, interesting case |
| 14:00 | <annevk> | zewt: actually in that case it would deliver the ping |
| 14:00 | <annevk> | zewt: at HEADERS_RECEIVED the ping is already at the other side |
| 14:01 | <annevk> | zewt: which does argue that the upload related check is wrong... |
| 14:05 | <zewt> | annevk: can you clarify the and/or gruoping in that section |
| 14:06 | <zewt> | An ... (state is opened and send() flag is set), (state is RECEIVED), or (state is LOADING and one of the following is true)? |
| 14:06 | <zewt> | also grouping |
| 14:07 | <zewt> | (that's what it seems like based on what it's trying to do, just a bit unobvious from a naive reading) |
| 14:07 | <annevk> | Hehe, source has "Based on EventSource and WebSocket. Not sure what I am doing." |
| 14:08 | <zewt> | might argue that this is okay from an event API standpoint, because the difference is unobservable to script (it just means "if there are listeners to hear it, do keep going"), but ... |
| 14:09 | <zewt> | so in this case i guess what it's really doing is saying "if nobody is listening, you don't actually have to read the whole POST body" |
| 14:10 | <Ms2ger> | In a tree falls in the forest... |
| 14:10 | <zewt> | maybe that's arguably an implementation detail anyway |
| 14:10 | <Ms2ger> | *If, dammit |
| 14:10 | <zewt> | forest.dispatchEvent(new Event("TreeFell")); |
| 14:12 | <zewt> | surprised that websocket is spying on event listeners, i thought that was only done with event handlers |
| 14:12 | <annevk> | zewt: added a commit |
| 14:13 | <annevk> | zewt: it's only about the response body |
| 14:14 | <annevk> | zewt: might be observable from the server if the UA actively kills the connection |
| 14:14 | <zewt> | right, but there are plenty of things we seem okay with being observable from the server that we're not in script... |
| 14:14 | <zewt> | (resource caching behavior, etc) |
| 14:16 | <zewt> | the upload events flag is the bigger one, though |
| 14:19 | <zewt> | afk, heading to work |
| 14:23 | <annevk> | Yeah, not sure how to fix that or if |
| 14:23 | <annevk> | "Invariants" seem to be screwed over left and right |
| 15:12 | <Domenic_> | annevk: you forgot to add `s around your HTML tags so your issue makes no sense :P |
| 15:13 | <annevk> | Domenic_: fixored |
| 15:14 | <annevk> | Domenic_: seems weird GH removes stuff it doesn't do anything with |
| 15:16 | <annevk> | Domenic_: what behavior-only objects are you talking about? |
| 15:16 | annevk | hasn't seen many |
| 15:17 | <Domenic_> | annevk: I'm trying to get the spec editor to tell me if there's hidden state, but https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-SubtleCrypto seems at first glance to be behavior-only. |
| 15:19 | <annevk> | Domenic_: with functions that access privileged APIs elsewhere somehow? |
| 15:19 | <Domenic_> | annevk: I don't understand the question? |
| 15:20 | <annevk> | Domenic_: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-SubtleCrypto-method-encrypt can't be implemented without "magic" |
| 15:20 | <Domenic_> | annevk: why do you say that? It just runs some well-specified algorithms, which are accessible to any Turing machine. |
| 15:22 | <annevk> | Domenic_: as in, all those functions want to share some algorithms, such as "normalize" |
| 15:22 | <annevk> | (which appears to be a broken link...) |
| 15:22 | <Domenic_> | Sure, functions can call other functions ... |
| 15:24 | <annevk> | Domenic_: anyway, any other examples? |
| 15:26 | <Domenic_> | annevk: https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html#idl-def-StorageQuota, given that supportedTypes is a constant (not mutable state) |
| 15:28 | <annevk> | That has NoInterfaceObject, so can you distinguish it from an ordinary object? |
| 15:30 | <Domenic_> | annevk: I believe Object.getPrototypeOf(navigator.storageQuota) would give back a StorageQuota, not Object. |
| 15:30 | <Domenic_> | even if window.StorageQuota doesn't exist. |
| 15:30 | <annevk> | Ah, I suspect that's probably true |
| 15:31 | <Domenic_> | Yeah, first sentence of http://heycam.github.io/webidl/#interface-prototype-object |
| 15:38 | <annevk> | Modules and IDL support for them is what we need for a lot of this stuff |
| 15:38 | <Domenic_> | indeeeed |
| 15:38 | <Domenic_> | probably worth waiting on implementations for that though. |
| 15:38 | <annevk> | Do modules have a concept of being scoped to particular types of realms? |
| 15:38 | <annevk> | E.g. we can't have DOM in workers... |
| 15:39 | <Domenic_> | I imagine different realms would have different built-in module loaders, and thus different built-in modules. |
| 16:21 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <Ms2ger> | cwilso, I got the eternal question from our implementor... Why XML and Http in XHR? |
| 16:37 | <Ms2ger> | Length? |
| 16:40 | <annevk> | Conventions |
| 16:40 | <annevk> | It was HttpRequest shipped as part of the XML library |
| 16:41 | <SamB> | see /topic ? |
| 16:41 | <annevk> | :) |
| 16:42 | <SamB> | though I guess actually people are actually after the story |
| 16:42 | <SamB> | +sometimes |
| 16:42 | <SamB> | -actually |
| 16:42 | <Ms2ger> | I'm certainly not going to suggest implementing XmlHttpRequest in Servo |
| 16:42 | <jgraham> | Well no |
| 16:43 | <jgraham> | If you were picking the name you would probably choose Request |
| 16:43 | <Ms2ger> | And not implement this API at all |
| 16:43 | <annevk> | You'd pick fetch and you'd pass it a Request |
| 16:43 | <annevk> | oh wait |
| 16:54 | <Hixie> | the inspecting of event listeners is to make GC not observable |
| 16:57 | <zewt> | grr is there nothing less crappy than gettext for python localization |
| 17:00 | <SamB> | is there ever anything less crappy than gettext? |
| 17:00 | <SamB> | I mean, for the same purpose |
| 17:00 | SamB | prepares to take notes |
| 17:01 | <zewt> | dunno, i just want something not crappy |
| 17:01 | <SamB> | well, what about it is your problem? |
| 17:04 | <zewt> | at the moment it happens to be fighting with pygettext, which apparently has no support for extracting comments for strings |
| 17:06 | <SamB> | that does look bad |
| 17:09 | <SamB> | zewt: have you tried xgettext? |
| 17:13 | <SamB> | zewt: it appears to be *intended* to work with Python, and it of course supports such things |
| 17:43 | <Manishearth> | Ms2ger: why do we have readyState in XMLHttpRequest as a `short`? |
| 17:44 | <Ms2ger> | Why not? |
| 17:45 | <Manishearth> | Ms2ger: it runs from 0-4. And I don't think that's going to increase much -- at least not above 8 |
| 20:19 | <TabAtkins> | annevk: GH doesn't "remove stuff it doesn't do anything with". If you don't wrap HTML elements in `s, *they're HTML elements*, and so you don't see them in the visible text obviously. |
| 20:40 | <zewt> | i don't know any good reason to specify ints as "shorts" in most cases, they're just integers |
| 20:40 | <zewt> | SamB: works a bit better, but seems to suck at recursively handling file trees... |
| 20:40 | <Domenic_> | TabAtkins: it probably sanitizes them though. |
| 20:41 | <SamB> | zewt: isn't that what find is for |
| 20:41 | <TabAtkins> | Domenic_: Possibly, yeah. |
| 20:41 | <zewt> | sure, but i'm having to jump a lot of hoops |
| 20:41 | <TabAtkins> | I know it allows <img> and such through. |
| 20:41 | <zewt> | i need to say xgettext -j to make it combine with a previous execution (in case xargs splits it into multiple invocations)... but that means I need to delete the file before running it, so it doesn't join with a previous execution... but if I say -j when the file *doesn't* already exist, it throws an error |
| 20:41 | <SamB> | yeah, what the heck is short |
| 20:41 | <SamB> | (are there any specs that already use short for something?) |
| 20:42 | <SamB> | zewt: hmm. |
| 20:42 | <zewt> | so i have to delete the file, then only add -j on the second and further invocations, which i don't know how to do with xargs |
| 20:42 | <zewt> | there's a -D "add DIRETORY to list for input files search" which sounds like what I want, but it doesn't seem to actually work |
| 20:42 | <SamB> | zewt: maybe --files-from= helps? |
| 20:43 | <zewt> | it also says "If input file is -, standard input is read", which should let me avoid xargs entirely, but that doesn't seem to work either |
| 20:43 | <SamB> | I think -D is for if you don't know where the files actually are |
| 20:44 | <SamB> | possibly to make things "easier" for out-of-tree builds |
| 20:44 | <zewt> | the word "footgun" comes to mind |
| 20:44 | <SamB> | hence the scare quotes |
| 20:45 | <SamB> | I don't know, maybe it's actually possible to use it in a useful way |
| 20:45 | <zewt> | wonder if the python gettext module has code to compile .po's so i can do it at runtime, precompiling to .mo is pointless for me (it's a server) |
| 20:46 | <SamB> | http://docs.python.org/library/gettext should have the answer |
| 20:46 | <zewt> | oh well, guess i'll write a script to invoke xgettext, it'll take less time |
| 20:46 | <SamB> | zewt: so did you try --files-from=<(find ...) |
| 20:47 | <zewt> | wouldn't i have to output the file list to a temp file (maybe --files-from=- works) |
| 20:47 | <zewt> | oh hey that does seem to work |
| 20:47 | <SamB> | yes it does |
| 20:48 | <SamB> | it doesn't know what the heck to do with CWEB's .w files, but boy does it find them |
| 20:48 | <zewt> | i think my stuff is encapsulated enough that it won't run into a bunch of stuff to confuse it |
| 20:48 | <SamB> | I was just trying a random example that'd work in the tree I was in |
| 20:49 | <zewt> | like when I was trying to package a web view's javascript files inside a Unity package, which Unity promptly interpreted as JS and tried to run as Unity code |
| 20:49 | <zewt> | thanks, stop that |
| 20:49 | <SamB> | mostly in case I was not remembering my shell syntax correctly |
| 20:49 | <zewt> | gettext is still very... 90s? |
| 20:50 | <SamB> | woah, copyright starts in '95 ? |
| 20:50 | <SamB> | I was expecting '8x |
| 20:54 | <SamB> | hmm, changelog for GCC starts in '91 with "Freshly created ChangeLog."; no idea when gcc was created |
| 20:54 | <Ms2ger> | "GCC 1.0 was released in 1987" |
| 20:55 | SamB | goes to do "git log Makefile.in" in the binutils-gdb repo, which is subsetted from the old src/ repo ... |
| 20:56 | SamB | tries again "git log -- Makefile" ... |
| 20:57 | <SamB> | nothing |
| 21:48 | <zewt> | "1.0 released in 1987" suggests they started on it circa 1972 |
| 21:58 | <Hixie> | hmm |
| 21:59 | <Hixie> | it's apparently been a while since i read my bugmail |
| 21:59 | <Hixie> | 4,767 e-mails... |
| 21:59 | <Hixie> | (and that's after filtering) |
| 22:25 | <Domenic_> | TabAtkins: can you use "internal slots" and [[x]] in http://dev.w3.org/csswg/css-font-loading/, instead of "internal attributes" and [x] ? |
| 22:25 | <Domenic_> | TabAtkins: we want to encourage more people to do that kind of thing, but it's harder to argue for when everyone is doing something different. |
| 22:29 | <TabAtkins> | Domenic_: Absolutely. |
| 22:30 | <TabAtkins> | Though using [[]] is kinda annoying in Bikeshed. Hmm. |
| 22:30 | <TabAtkins> | I think I can write [<!---->[foo]]. |
| 22:30 | <Domenic_> | TabAtkins: awesome, thanks! And, uh, wow that sounds hard. |
| 22:32 | <TabAtkins> | It's just that Bikeshed treats [[foo]] as a biblio ref. |
| 22:33 | <Domenic_> | ah tricksy |
| 22:33 | <TabAtkins> | (A behavior inherited from the old CSSWG preprocessor, and shared by Anolis, I think.) |
| 22:33 | <Domenic_> | ah i see, so a behavior that would move peoples' cheese if changed |
| 22:34 | <Domenic_> | The only thing I can think of is inventing something arcane that gets translated to [[x]], e.g. \\x// |
| 22:34 | <TabAtkins> | Yeah, it would break virtually every Bikeshedded spec if changed. |
| 22:34 | <jgraham> | What kind of cheese is this, and — assuming it is nice cheese — could they move it this way? |
| 22:34 | <TabAtkins> | What I might do instead is add a metadata field to let you specify things that aren't biblio refs. |
| 22:35 | <TabAtkins> | For now, though, I'm just adding a comment to break things up. |
| 22:35 | <Domenic_> | We do want to add internal slot declarations to WebIDL of some sort |
| 22:35 | <TabAtkins> | Cool. |
| 22:36 | <TabAtkins> | Just checked - ReSpec uses that syntax too. |
| 22:36 | <Domenic_> | waaah waaaaah |
| 22:36 | <TabAtkins> | Any chance y'all could come up with a syntax that doesn't directly impinge on every extant spec preprocessor? |
| 22:37 | <Domenic_> | i mean, we could ask ES to change, but seems unlikely... |
| 22:37 | <Domenic_> | or we could just be inconsistent with ES... |
| 22:37 | <Domenic_> | but they're supposed to be the same concept |
| 22:37 | <TabAtkins> | I'm fine with the latter. |
| 22:37 | <SamB> | don't suppose you could ask them not to process the IDL for bibliographic references |
| 22:37 | <TabAtkins> | SamB: It won't just appear in IDL. |
| 22:37 | <Domenic_> | i'm a bit surprised that it doesn't leave [[x]]s alone if there's no x in the references section. |
| 22:37 | <TabAtkins> | It's scattered throughout the spec, every time you reference the slot. |
| 22:38 | <TabAtkins> | Domenic_: A good preprocessor *tells* you you've made a typo when it can't find "x" in the refs database. |
| 22:38 | <Domenic_> | yeah, that makes sense. |
| 22:38 | <TabAtkins> | And they *generate* the references sections (that's why preprocessor exist) |
| 22:38 | <Domenic_> | oh right i forgot about that feature. |
| 22:38 | <Domenic_> | using the database of well-known references |
| 22:38 | <TabAtkins> | Yup. |
| 22:39 | <TabAtkins> | You people writing specs in GHMarkdown are missing out on a lot. ^_^ |
| 22:39 | <Domenic_> | I guess I'd say use {{x}} in source and have preprocessor convert to [[x]] |
| 22:39 | <Domenic_> | heh |
| 22:39 | TabAtkins | is getting closer to having most of Markdown implemented in Bikeshed. |
| 22:39 | <SamB> | I never quite understood how that part was supposed to work with each thing in its own repository, but then I'm thinking of bibTeX ... |
| 22:39 | <TabAtkins> | SamB: What part? |
| 22:39 | <SamB> | the part where you have a big database |
| 22:40 | <TabAtkins> | You keep a master database of refs that everyone updates. |
| 22:40 | <SamB> | easier with spec tools |
| 22:40 | <TabAtkins> | The biblio dbs are maintained automatically. Bikeshed's linking database is done automatically, though. |
| 22:40 | <TabAtkins> | Once it knows a spec's location, it stays up-to-date. |
| 22:41 | <TabAtkins> | SamB: I don't understand what you mean. |
| 22:41 | <Domenic_> | so what you're saying is, there's only one place we have to change [[HTML]]'s URL in, and then everything will be better... |
| 22:41 | <TabAtkins> | Domenic_: Yes. |
| 22:41 | <TabAtkins> | ([[HTML]] already points to the proper spec in Bikeshed's DB.) |
| 22:41 | <Domenic_> | nice |
| 22:42 | <TabAtkins> | (Though [[HTML5]] points to the W3C spec.) |
| 22:43 | <TabAtkins> | Domenic_: I can always give you a Bikeshed crash-course if you want. It works fine with the GH workflow - <picture>'s spec is Bikeshedded, and uses a gh-pages as master for displaying. |
| 22:45 | <Domenic_> | TabAtkins: probably a good idea, when it's time for me to get serious about prettifying streams. I'll let you know ^_^ |
| 22:46 | <TabAtkins> | kk, but Bikeshed is helpful during initial writing too, as it makes sure you don't typo links and such. |
| 22:46 | <TabAtkins> | Let's you draw railroad diagrams. |
| 22:46 | <TabAtkins> | Other cool things. _^ |
| 22:58 | <Hixie> | [[HTML5]] should be a fatal error :-P |
| 23:53 | <TabAtkins> | Domenic_: Why are [[Foo]] things called private slots rather than private attributes? |
| 23:54 | <Domenic_> | TabAtkins: attributes is a WebIDL-ism. |
| 23:55 | <Domenic_> | They used to be called internal data properties in ES |
| 23:55 | <Domenic_> | then we thought that was confusing since you can't e.g. getOwnPropertyDescriptor them |
| 23:55 | <Domenic_> | also it was long |
| 23:55 | <Domenic_> | so they became internal slots |
| 23:55 | <TabAtkins> | Okay. |
| 23:55 | <TabAtkins> | Anyway, just pushed the change to Font Loading. |
| 23:56 | <TabAtkins> | May take a few minutes to show up. |
| 23:57 | <Domenic_> | yaaaay :) thanks man |