| 01:42 | <MikeSmith> | TabAtkins: I got a question about bikeshed handling of refs when somebody wants a section ref to a section in a different spec |
| 01:42 | <MikeSmith> | TabAtkins: see https://github.com/w3c/webappsec-csp/blob/master/document/index.src.html#L48 |
| 01:43 | <MikeSmith> | ...where mkwst has: |
| 01:43 | <MikeSmith> | spec: CSP; urlPrefix: https://w3c.github.io/webappsec-csp |
| 01:43 | <MikeSmith> | type: section |
| 01:43 | <MikeSmith> | text: lalala; url: match-url-to-source-list |
| 01:44 | <MikeSmith> | then in the body of the source, he references that like this: |
| 01:44 | <MikeSmith> | 4. If the result of executing [[#match-url-to-source-list]] on |base| and |
| 01:45 | <MikeSmith> | but bikeshed flags that ref as an error, apparently because it's looking for that section ID in that same doc instead of in the CSP spec |
| 01:47 | <MikeSmith> | not sure why he's not just doing [[!match-url-to-source-list]] instead but I imagine he's got a good reason (maybe because he wants the section number to appear?) |
| 01:48 | <TabAtkins> | MikeSmith: Section links aren't covered by the autolinking block. But if the spec is in either Bikeshed or Specref, [[spec#anchor]] works |
| 01:48 | <MikeSmith> | oh |
| 01:49 | <MikeSmith> | lemme try that |
| 01:50 | <TabAtkins> | Use whatever spec name would work with a normal biblio link [[foo]] |
| 01:51 | <MikeSmith> | ok thanks |
| 01:51 | <MikeSmith> | I see that renders as "If the result of executing Content Security Policy §match-url-to-source-list on base and source list is " |
| 01:52 | <MikeSmith> | so I'm guessing mkwst probably doesn't want the "Content Security Policy" text there, and he wants some particular string in place of "match-url-to-source-list" |
| 01:52 | <TabAtkins> | Yeah, so it's in SpecRef only, so I don't know the section name. |
| 01:53 | <MikeSmith> | OK, anyway, rather than me speculating further about what his intent was, I'll just wait and ask him when he's around |
| 01:53 | <TabAtkins> | Oh, from context, he just wants an autolinking anyway, not a section link. |
| 01:54 | <MikeSmith> | ok |
| 01:56 | <MikeSmith> | TabAtkins: btw I was also kinda surprised to see the bikeshed docs for OSX install recommending to install through port/MacPorts rather than brew |
| 01:56 | <TabAtkins> | So change the autolinking block to "type: dfn", and the link itself to <a>...</a>. |
| 01:57 | <TabAtkins> | I have no clue about Mac install instructions. Those were written by someone else. |
| 02:02 | <MikeSmith> | OK will ask Mike about making that change. I don't care strongly either way about how he chooses to mark it upーI just want to be able to build it without errors when I submit patches against the source :) |
| 02:04 | <MikeSmith> | ah OK about the Mac install instructions I guess I could write a patch but maybe I shouldn't step on whoever did the original writeup. Don't want to get into an unproductive MacPorts-vs-Homebrew rathole |
| 05:47 | <TabAtkins> | MikeSmith: Feel free to write alternate instructions, so people can choose either. |
| 05:57 | <annevk> | TabAtkins: that is correct, I really need to clean up HTML one day |
| 05:57 | <TabAtkins> | annevk: In the meantime, I've cleaned up FileAPI. |
| 05:57 | <annevk> | Cool |
| 05:57 | <TabAtkins> | And put an issue on HTML for you. ^_^ |
| 06:06 | <mkwst> | MikeSmith, TabAtkins: Ah. I didn't actually mean to commit that. I was playing around, trying to make cross-spec section links work. |
| 06:08 | <mkwst> | Apparently TabAtkins poked at https://github.com/tabatkins/bikeshed/issues/528 for me while I wasn't looking, so I'll update to use that. |
| 06:09 | <mkwst> | I still want some mechanism for links to editor's drafts of specs I have locally that aren't in SpecRef, which I don't think exists. |
| 06:09 | <TabAtkins> | Also: go comment on the dfn-link shorthand thread! |
| 06:09 | <TabAtkins> | Yeah, doesn't exist yet. |
| 06:09 | <mkwst> | (And, in this particular case, I'd ideally have the section name, just as I would if I was linking inside a document) |
| 06:10 | <mkwst> | (e.g. [[spec#section]] would turn into "<a href='whatever'>This is an amazing algorithm name that you put in a header!</a>" |
| 06:11 | <TabAtkins> | Anything which Bikeshed knows about acts like that. Just need to put more specs into Bikeshed - feel free to file issues and I'll get to it. |
| 06:11 | <mkwst> | Ok. I'll go file some issues, then. How often does Bikeshed update its database? |
| 06:12 | <TabAtkins> | Several times an hour. |
| 06:12 | <TabAtkins> | Or that might be just for the CSS specs it tracks. At least daily, then. |
| 06:14 | <TabAtkins> | And upcoming is an ability to manually load up Bikeshed with definitions from non-Bikeshedded specs, without having to spam them locally into every spec with a <pre class=anchors>. |
| 06:14 | <TabAtkins> | So then we can just PR Bikeshed to add more stuff. |
| 06:16 | <mkwst> | Great. I do that all the time. It's a bit annoying. |
| 06:16 | <mkwst> | Like, Fetch. Just get Fetch in, and that will take care of ~50% of the links I embed. :) |
| 06:17 | TabAtkins | nudges annevk |
| 06:19 | <mkwst> | It'll be some work. I don't think Fetch has the `for` concept, like HTML, so it probably will end up with naming conflicts that differ by ID. |
| 06:20 | <TabAtkins> | Nothing preventing it from adding appropriate `for` values, like DOM did. |
| 06:20 | <TabAtkins> | Or URL. |
| 06:22 | <mkwst> | Yup. It'll just be some busywork. |
| 06:30 | <yhirano_> | annevk: Can you tell me the meaning of "body length" in the fetch spec? I noticed I didn't understand the step 10.1 in 5.5 HTTP-network fetch... |
| 06:40 | <MikeSmith> | mkwst: thanks, I guess the "lalala" should have clued me in that it was something maybe not intended to have been committed 😆 |
| 06:41 | <MikeSmith> | good to see that spec is headed for FPWD |
| 06:42 | <MikeSmith> | mkwst: on that note, been wondering if you now whether Referrer Policy is going to FPWD any time soon |
| 06:43 | <MikeSmith> | also been wondering the same about the Suborigins spec |
| 07:28 | <annevk> | yhirano_: it's something for XMLHttpRequest's ProgressEvent |
| 07:28 | <annevk> | yhirano_: basically that it has some values |
| 07:30 | <annevk> | TabAtkins: mkwst: although bikeshed is in some aspects much better than ReSpec, a love the predictability of the latter (and the better formatting) |
| 07:30 | <annevk> | TabAtkins: mkwst: I think that's mostly why I haven't gone out of my way personally to convert specifications |
| 07:32 | <TabAtkins> | Better formatting? |
| 07:32 | <TabAtkins> | Wait, you don't use ReSpec for *anything*, anne. |
| 07:33 | <TabAtkins> | Do you mean Anolis? |
| 07:39 | <annevk> | TabAtkins: oops, yes |
| 07:40 | <annevk> | TabAtkins: clear sign there's too many of these 😊 |
| 07:40 | <yhirano_> | annevk: the step 10 in HTTP-network fetch runs in parallel: When will 10.1 run? As soon as possible? |
| 07:40 | <annevk> | yhirano_: yeah, it basically doesn't block anything else that Fetch does |
| 07:41 | <annevk> | TabAtkins: some specific things, e.g., if I have a single <p> inside an <li>, I don't want breaks around it |
| 07:42 | <annevk> | TabAtkins: if I omit closing tags, I don't want a trailing space in the output if that doesn't omit closing tags |
| 07:42 | <yhirano_> | annevk: Is "response's body's payload length" available at that time? |
| 07:42 | <annevk> | yhirano_: per HTTP/1 that'd be Content-Length |
| 07:42 | <annevk> | yhirano_: so it should be |
| 07:43 | <annevk> | yhirano_: though I guess perhaps it should account for payload length being unknown |
| 07:43 | <annevk> | yhirano_: you're rewriting this algorithm, no? To account for streams? |
| 07:43 | <yhirano_> | annevk: yes. |
| 07:44 | <annevk> | TabAtkins: it also still bugs me that sometimes if I do <a spec=x>...</a> it will not exclusively look at x |
| 07:45 | <annevk> | TabAtkins: and the whole linking toolchain is geared towards W3C, which makes cross-specification linking harder than it should be |
| 07:45 | <annevk> | TabAtkins: likely in part because they fork and both specifications end up getting indexed, squat on the same name, etc. |
| 07:47 | <yhirano_> | annevk: Then can't XHR read directly from the response header? |
| 07:51 | <annevk> | yhirano_: does HTTP/2 not have a different way to convey this? If not, perhaps |
| 07:52 | <annevk> | yhirano_: it seems cleaner to me to let the network layer parse and interpret the header as the network layer might want to use that data for various reasons anyway |
| 07:52 | <annevk> | yhirano_: not entirely sure it's worth doing it twice, potentially with different results |
| 07:53 | <yhirano_> | annevk: hm, I see, thanks. |
| 08:22 | <ritsyy> | annevk: in reference to this issue https://github.com/whatwg/html/issues/513 could you tell me a bit about the content types that should be handled in "the embed element" |
| 08:23 | <annevk> | ritsyy: it basically needs to do something very similar to what the <object> element does |
| 08:23 | <annevk> | ritsyy: which is quite involved |
| 08:24 | <ritsyy> | annevk: okay like all the associated content-type metadata and other handlers in object element? |
| 08:26 | <annevk> | ritsyy: it basically needs to handle all types of content, instead of just plugins and SVG |
| 08:27 | <annevk> | ritsyy: see step 9 of the big algorithm in the <object> section in particular |
| 08:28 | <ritsyy> | annevk: yeah, getting it now |
| 08:34 | <youenn> | annevk: hi |
| 08:35 | <youenn> | annevk: about https://github.com/whatwg/fetch/issues/189, I am wondering whether multiple headers with the same name but not combinable should be made unsupported by fetch headers API. |
| 08:36 | <youenn> | ... In WebKit, mac network backend will not support them. And, IIANM, Fetch API is not defining any header serialization rule, which is ok as long as serialization variants are semantically equivalent. |
| 09:00 | <annevk> | youenn: well, XMLHttpRequest has serialization |
| 09:00 | <annevk> | youenn: and Fetch has iteration |
| 09:01 | <annevk> | youenn: and I believe some browsers treat X: 1, 2, 3 different from X: 1, 2\nX: 3 |
| 09:01 | <annevk> | youenn: e.g., if X is Location, I think some browsers might parse "1, 2" as a URL... |
| 09:02 | <annevk> | youenn: now whether that behavior is acceptable is of course questionable, and I guess from what you're saying Safari wouldn't do that |
| 09:02 | <annevk> | youenn: I do wonder how the cookie situation is handled though, that was another reason why other browsers have these more advanced data structures |
| 09:03 | <youenn> | annevk: XHR has serialization for combinable headers only AFAIK |
| 09:03 | <youenn> | annevk: for cookies, I am not sure how mac is handling, I do not know this binding well. |
| 09:03 | <youenn> | But looking at RFC 7230, these should be treated as special case headers. |
| 09:04 | <youenn> | annevk: With this API, we are making them prime citizens... |
| 09:04 | <youenn> | ... which would mandate browsers to serialize headers precisely as web applications are specifiyng headers. |
| 09:06 | <annevk> | youenn: so maybe we should have a short email discussion among the various browsers and some other folks and copy www-archive to see what's what |
| 09:07 | <youenn> | annevk: it would be good to know whether the issue is all about Cookie, or whether other cases arise (like Location you mentioned). |
| 09:07 | <youenn> | ... What would be the best venue for this discussion? |
| 09:08 | <annevk> | youenn: I'll start a discussion, do you want anyone copied? |
| 09:09 | <youenn> | annevk: I guess it would be good to have mac folks in the loop: alex christensen at least, who may forward the information if needed to whoever appropriate. |
| 09:10 | <annevk> | youenn: sure, what's their email? |
| 09:12 | <youenn> | achristensen⊙wo |
| 09:14 | <youenn> | annevk: Maybe hober (cf github issue as well) |
| 09:14 | <annevk> | ok |
| 09:27 | <annevk> | youenn: https://lists.w3.org/Archives/Public/www-archive/2016Jan/0006.html |
| 09:29 | <youenn> | annevk: thanks |
| 10:06 | <Ms2ger> | Argh |
| 10:06 | <Ms2ger> | How do I get the actual most recent ES spec? |
| 10:08 | <jgraham> | Ms2ger: It depends. Do you have a goat to hand? |
| 10:08 | <Ms2ger> | I don't |
| 10:08 | <jgraham> | ah, I think that's a prequisite |
| 10:09 | <AutomatedTester> | I only know of the one on jorendorff's people account |
| 10:09 | <Ms2ger> | I need one that's a lot more recent :) |
| 10:09 | <Ms2ger> | https://tc39.github.io/ecma262/ is too old |
| 10:10 | <Ms2ger> | Calling Domenic |
| 10:11 | <annevk> | Ms2ger: that is too old? I guess you need to ask bterlson then since I thought that was supposed to be master |
| 10:11 | <Ms2ger> | It doesn't have https://github.com/tc39/ecma262/pull/275 |
| 10:11 | <Ms2ger> | bterlson, aloha |
| 10:12 | <jgraham> | Ms2ger: git clone git⊙gc:tc39/ecma262.git and read spec.html? |
| 10:12 | <annevk> | Ms2ger: hmm yeah, it seems stuff is pushed to gh-pages manually, bah |
| 10:13 | <Ms2ger> | jgraham, spec.html is not html, so yay |
| 10:13 | <jgraham> | Oh, you need some crazy node based build system? |
| 10:13 | <jgraham> | But of course |
| 10:14 | Ms2ger | has avoided installing npm so far |
| 10:14 | <jgraham> | Ms2ger: In any case file a PR to get auto-deploy to gh pages working |
| 10:15 | <jgraham> | I'm surprised it isn't already since Domenic wrote one of the highest ranked documents on how to do that |
| 10:57 | <zcorpan> | MikeSmith: fyi https://github.com/whatwg/html/issues/534 |
| 11:04 | <zcorpan> | ritsyy: there are some differences that should remain between the two though, e.g. <embed> doesn't ever fall back to showing its children, and <embed> should happily render a 404 response |
| 11:05 | <ritsyy> | annevk: okay i will test the content type behaviours for other browsers, |
| 11:06 | <annevk> | zcorpan: yeah, and I guess <embed> will keep doing its extension sniffing |
| 11:06 | <zcorpan> | yes |
| 11:07 | <ritsyy> | zcorpan: yeah that is a difference |
| 11:13 | <zcorpan> | annevk: ritsyy: though <object> checks file extension as well |
| 11:14 | <annevk> | zcorpan: it does? hmm |
| 11:15 | <annevk> | it does, sad |
| 11:17 | <ritsyy> | zcorpan: oh yes it does check :-( |
| 11:49 | <MikeSmith> | zcorpan: about https://github.com/whatwg/html/issues/534 thanks and I saw your specific question and will read and respond there later |
| 11:49 | <zcorpan> | MikeSmith: thx! |
| 11:53 | <MikeSmith> | wonder why they're just not auto-(re)publishing https://github.com/tc39/ecma262 for every push |
| 11:54 | <MikeSmith> | https://rawgit.com/tc39/ecma262/master/spec.html seems not completely unreadable/unusable though |
| 11:55 | <MikeSmith> | no info in the repo about how to build the processed output though (so can't even view the latest locally) |
| 11:56 | <MikeSmith> | I guess it must need https://github.com/bterlson/ecmarkup though |
| 11:56 | <MikeSmith> | npm install ecmarkup |
| 11:56 | <MikeSmith> | ecmarkup in.html out.html |
| 11:56 | <Ms2ger> | MikeSmith, the readme explains, no? |
| 11:57 | <MikeSmith> | oh |
| 11:57 | <MikeSmith> | well, didn't read that |
| 11:57 | <Ms2ger> | Developing the Specification |
| 11:57 | <Ms2ger> | After cloning, do npm install to set up your environment. You can then do npm run build to build the spec or npm run watch to set up a continuous build. The results will appear in the out directory, which you can use npm run clean to delete. |
| 11:58 | <MikeSmith> | well there you go |
| 11:58 | <MikeSmith> | now I wonder what you were complaining about! |
| 11:59 | <MikeSmith> | since it says right there what you need to do to read the latest version |
| 12:02 | <Ms2ger> | $ npm |
| 12:02 | <Ms2ger> | The program 'npm' is currently not installed. |
| 12:02 | Ms2ger | is quite happy to keep it that way |
| 12:54 | <annevk> | zcorpan: "Image container" |
| 12:56 | <annevk> | ritsyy: FWIW, when you address feedback in a PR, it might help to leave a comment once you're done, since otherwise it doesn't appear in my notifications tab and I'll basically assume nothing happened |
| 12:56 | <zcorpan> | annevk: too late :-P |
| 12:56 | <annevk> | ritsyy: I think the same goes for other people, though maybe not everyone uses GitHub notifications the way I do |
| 12:57 | <annevk> | ritsyy: (I just noticed you pushed updates to the <iframe seamless> removal PR) |
| 12:57 | <annevk> | zcorpan: heh |
| 12:57 | <zcorpan> | yeah same here |
| 13:34 | <smaug____> | is there some easy way to look at IDs in html spec to get good link to certain place? I always select the relevant text, look at selection source and find some ID in there, but that isn't too handy |
| 13:37 | <annevk> | smaug____: not really |
| 13:38 | <annevk> | smaug____: I assume you know you can click on <dfn>s and get the link that way |
| 13:38 | <annevk> | smaug____: that's probably the easiest way, though doesn't work for sections and such |
| 13:38 | <ritsyy> | annevk: yeah i will fix this habit of mine, i'll comment on the PR while doing the changes :) |
| 13:39 | <smaug____> | annevk: yeah, in some cases clicking does reveal a popup, that captures only a small subset |
| 13:39 | <smaug____> | annevk: how stable are the IDs? |
| 13:39 | <zcorpan> | smaug____: the "file an issue" link creates a link for the selection, though it isn't always a useful one (and not so convenient either if you're not filing an issue) |
| 13:39 | smaug____ | doesn't know how the IDs are generated |
| 13:40 | <zcorpan> | smaug____: not particularly stable :-( |
| 13:40 | <annevk> | they should be pretty stable though |
| 13:41 | <annevk> | many fragments work for a long time |
| 13:43 | <zcorpan> | i suppose it's mostly bad for headings that have the same text content in many places, e.g. "Introduction" |
| 13:43 | Ms2ger | uses devtools |
| 13:44 | <Ms2ger> | zcorpan, "document" |
| 13:45 | <zcorpan> | Ms2ger: is that one not stable? |
| 13:46 | <annevk> | Also, if you need an ID to be stable, there are ways of making it stable, by just inserting it in the source |
| 13:46 | <annevk> | We can certainly do that |
| 13:46 | <zcorpan> | oh i suppose instances of "document" are not |
| 13:47 | <Ms2ger> | Apparently not: https://github.com/servo/servo/pull/9328 |
| 13:47 | Ms2ger | goes back to implementing modules |
| 13:49 | <zcorpan> | smaug____: btw want to check https://github.com/whatwg/html/pull/508 ? |
| 13:52 | <zcorpan> | Ms2ger: i... don't know what's going on there. #dom-document-0 and #dom-document-1 redirect to #browsers |
| 14:08 | <smaug____> | so in github one can't really associate a pr with an issue? |
| 14:08 | <smaug____> | it is just some random #123 which may or may not get noticed within all the other comments in the bug? |
| 14:17 | <zcorpan> | smaug____: right :-/ |
| 14:17 | <Ms2ger> | smaug____, if you put "Fixes #123" in the summary of a PR, the issue gets closed automatically when the PR is merged |
| 14:18 | <zcorpan> | Ms2ger: in the commit message, but yeah |
| 14:18 | <Ms2ger> | The PR summary works too |
| 14:19 | <zcorpan> | oh, ok. |
| 14:19 | <smaug____> | feels like tracking dependency chains is hard |
| 14:20 | <ritsyy> | annevk: What conflicts could be the reason of errors? |
| 14:21 | <Ms2ger> | People just don't track dependencies :) |
| 14:23 | <ritsyy> | annevk: did the changes https://github.com/whatwg/html/pull/499 , thank you! |
| 14:35 | <annevk> | ritsyy: you might want to rebase every now and then |
| 14:51 | <ritsyy> | annevk: yes i have rebased all the commits of this PR |
| 14:52 | <ritsyy> | annevk: oh ok it's done |
| 14:53 | <annevk> | ritsyy: it didn't seem rebased, since it failed to compile, after rebasing it did compile |
| 14:55 | <ritsyy> | annevk: but my git log shows one commit only, i don't know why that happened |
| 14:56 | <annevk> | ritsyy: one commit doesn't mean it's rebased |
| 14:56 | <annevk> | ritsyy: rebased means that the commit is new relative to master |
| 14:57 | <annevk> | ritsyy: well, that the branch is on top, I guess |
| 15:24 | <TabAtkins> | annevk: "single <p> inside an <li>, I don't want breaks around it" - what do you mean by that? And by your next line? |
| 15:25 | <TabAtkins> | The closing tag one confuses me, because there's no diff between omitting a closing tag and having the closing tag show up immediately prior to the next opening tag. Both will include any trailing space. |
| 15:25 | <annevk> | TabAtkins: if the input is "<li><p>Test." the output is "<li>\n <p>Test. </p>\n </li>" rather than "<li><p>Test.</p></li>" |
| 15:26 | <TabAtkins> | Ohhhh, yeah. Because I ended up writing a pretty-printer for output. |
| 15:26 | <famicom> | output of what (me just came in) |
| 15:26 | <annevk> | TabAtkins: agreed, but it looks ugly, either omit the closing tag, or place it where you'd expect it |
| 15:28 | <TabAtkins> | I could make the output smarter and omit closing tags when it's safe to do so, but I'd have to encode all the rules for when the following sibling won't merge into the <p>. |
| 15:28 | <TabAtkins> | famicom: Talking about the Bikeshed tool. |
| 15:28 | <zcorpan> | TabAtkins: good thing the html spec has rules for when it's safe to omit tags :-) |
| 15:28 | <TabAtkins> | Yeah but they're anoyyyyyying |
| 15:29 | <famicom> | yeah, but for the sake of consistency, don't |
| 15:29 | <famicom> | last time i checked short form wasn't allowed and most xml parsers will scream murder making polyglot docs a pain to write |
| 15:29 | <TabAtkins> | Good thing we're not writing XML, then. |
| 15:30 | <famicom> | *polyglot* |
| 15:30 | <TabAtkins> | Same thing. |
| 15:30 | <annevk> | Is polyglot still a thing? o_O |
| 15:30 | <jgraham> | famicom: It's not dead, just pining for the fjords? |
| 15:30 | <famicom> | annevk hell yeah it is |
| 15:31 | annevk | wonders who famicom is now |
| 15:31 | <TabAtkins> | Bikeshed does not actually output polyglot. |
| 15:31 | <TabAtkins> | And I have no particular plans to. |
| 15:31 | <famicom> | and bikeshed is? |
| 15:32 | <TabAtkins> | The tool we were discussing before you showed up. ^_^ |
| 15:32 | <famicom> | ah! |
| 15:32 | <annevk> | TabAtkins: to be fair, the additional newlines are the bigger nuisance, since it makes the output much longer |
| 15:32 | <famicom> | annevk, so just trim them? |
| 15:33 | <annevk> | TabAtkins: and the various linking systems being hard to figure out and not being deterministic is problematic |
| 15:33 | <TabAtkins> | Again, famicom, this is a tool's output we're talking about. |
| 15:33 | <famicom> | bikeshed <doc> | tr |
| 15:34 | <TabAtkins> | What do you mean by "deterministic"? (I'll cop to "hard to figure out" - that's the price for magic that "just works" 99% of the time.) |
| 15:35 | <annevk> | TabAtkins: well, that other documents can claim my terms |
| 15:35 | <famicom> | TabAtkins, "predictable" |
| 15:35 | <TabAtkins> | famicom: That would delete all newlines. That's not what's being asked for. |
| 15:35 | <TabAtkins> | annevk: Yeah, and that produces linking collisions, which are alerted on and which you can then correct for. |
| 15:36 | <TabAtkins> | You'll never silently change link targets unless one spec *deletes* a term, then another spec adds it. |
| 15:36 | <annevk> | TabAtkins: well, it didn't last time remember when UI Events redefined some stuff from DOM |
| 15:36 | <annevk> | TabAtkins: suddenly DOM started pointing to UI Events |
| 15:36 | <annevk> | TabAtkins: for <dfn>s that were inside DOM |
| 15:36 | <TabAtkins> | Ugh, right, that was my fault and I"m sorry for that. |
| 15:37 | <TabAtkins> | It *wasn't* for <dfn>s inside of DOM, it was for IDL that is normally ambiguous and can either become an <a> or a <dfn>, and I was non-determinstic on which it ended up with. |
| 15:37 | <annevk> | TabAtkins: the other thing that's weird is that even if I specify a name e.g., <a spec=url>url</a>, it'll still do a local lookup rather than exclusively rely on url.spec.whatwg.org |
| 15:38 | <TabAtkins> | I've "fixed" the IDL thing in a simple way now, because it was a mistake that I should never have made. I'll fix it more intelligently later. |
| 15:38 | <TabAtkins> | Hmm, yeah, I'm currently using spec purely as a "too many targets" disambiguator. I could take it as a stronger signal of intent and have it avoid local links, that would make sense. |
| 15:38 | <famicom> | TabAtkins, since you wrote bikeshed, got any idea if bs is appropriate to extract all normative sections from the specs automagically |
| 15:39 | <TabAtkins> | famicom: It doesn't currently offer such functionality, and you'd need to mark up normative vs informative in a machine-readable way. |
| 15:39 | <famicom> | is there any such tool available |
| 15:39 | <TabAtkins> | annevk: I'll log the spec thing as an issue and fix it, it'll be easy. |
| 15:40 | <annevk> | TabAtkins: there's also that thing since references come from different sources, https://dom.spec.whatwg.org/ ends up referencing selectors twice |
| 15:41 | <TabAtkins> | Yeah, that's an open bug on me still to figure out how to dedup Bikeshed's specs from SpecRef's versions. |
| 15:41 | <annevk> | TabAtkins: and "Terms defined by reference" only includes successful <a spec=...> stuff, not anything from anchors |
| 15:41 | <annevk> | TabAtkins: which makes it a bit weird |
| 15:41 | <TabAtkins> | Ohhh, interesting request. |
| 15:42 | <TabAtkins> | (All <pre class=anchors> stuff is treated as local right now, so you don't get linking ambiguity if that term happens to exist elsewhere, because you clearly communicated intent to link to this specific version.) |
| 15:43 | <annevk> | (I'd rather not need anchors at all I guess, but as long as it's needed I'd prefer it if the output at least didn't distinguish as much...) |
| 15:43 | <annevk> | Yeah, but anchors is mostly used for non-local stuff |
| 15:43 | <famicom> | TabAtkins, so how does one know weither the local version contains the latest version |
| 15:43 | <annevk> | At least, as far as I can tell |
| 15:43 | <TabAtkins> | Yeah, I'd prefer not needing it either, but until more specs are Bikeshed-friendly and in the linking database... |
| 15:43 | <famicom> | or weither the referenced link is authoritative |
| 15:43 | <TabAtkins> | annevk: Yeah, if you have an *actual* local anchor, it's just a <dfn> somewhere. |
| 15:44 | <TabAtkins> | famicom: ? |
| 15:44 | <famicom> | [16:42:59] <TabAtkins> (All <pre class=anchors> stuff is treated as local right now, so you don't get linking ambiguity if that term happens to exist elsewhere, because you clearly communicated intent to link to this specific version.) |
| 15:44 | <TabAtkins> | Yes, I get the reference, I just dont' understand your question. |
| 15:45 | <mven> | Hi all, can anyone tell me what the default font-size for an html page is? I keep hearing 16px, but I've dove into the default browser style sheets and haven't seen any definitive evidence that this is the case. Anyone have a spec that shows this? |
| 15:45 | <famicom> | sigh, most specs regarding html5 et all are rather scattered |
| 15:46 | <TabAtkins> | mven: It's based on user settings (thus not in the default style sheet), but it typically defaults to 16px. |
| 15:46 | <Ms2ger> | Is that specced? |
| 15:47 | <mven> | @TabAtkins So based on the user prefs in the browser? |
| 15:47 | <annevk> | mven: yup |
| 15:47 | <mven> | ahhh |
| 15:48 | <mven> | That makes sense. |
| 15:48 | <mven> | I couldn't find any info about it. Does anyone have a link to that? |
| 15:48 | <annevk> | Ms2ger: https://drafts.csswg.org/css-fonts/#font-size-prop does not seem to define that medium typically means 16px |
| 15:49 | <TabAtkins> | Correct, it's not defined anywhere. |
| 15:50 | <annevk> | Probably should be defined, since I suspect there's quite a few pages depending on it by now |
| 15:50 | <famicom> | annevk, based on what data? |
| 15:51 | <TabAtkins> | Based on the assumption that whenever something is agreed on by every single browser for decades, it's probably depended on. |
| 15:51 | <TabAtkins> | This is, like, one of the safest possible assumptions to make in this regard. |
| 15:51 | <famicom> | except for safari |
| 15:52 | <TabAtkins> | Are you saying that Safari does not default to 16px text on a clean install? |
| 15:52 | <annevk> | w(getComputedStyle(document.body).fontSize) returns 16px in Safari, not sure what famicom is talking about |
| 15:54 | <mven> | @TabAtkins @annevk thanks for the info. It's been helpful. |
| 15:57 | <TabAtkins> | annevk: https://github.com/tabatkins/bikeshed/issues/565 and https://github.com/tabatkins/bikeshed/issues/566 |
| 15:58 | <smaug____> | nox: what is the problem with text nodes and split? |
| 15:59 | <nox> | smaug____: Ranges are not updated correctly. |
| 15:59 | <nox> | If I have an orphan Text node of length 50, with a range spanning from 0 to 30, and I split at 20, |
| 15:59 | <annevk> | TabAtkins: ta |
| 15:59 | <nox> | what should happen to the range? |
| 15:59 | <smaug____> | range should be 0,20 |
| 16:00 | <smaug____> | per spec |
| 16:00 | smaug____ | re-reads the spec ;) |
| 16:00 | <nox> | smaug____: Can't read. |
| 16:00 | <nox> | :( |
| 16:00 | <nox> | Forgot step 9. |
| 16:00 | <smaug____> | "For each range whose end node is node and end offset is greater than offset, set its end offset to offset" |
| 16:01 | <annevk> | phew |
| 16:01 | <famicom> | sigh |
| 16:01 | <famicom> | if you have chosen a 12-point or "medium" font as your default (i.e., for body), then this should measure 16 points. If your display is at 96 dpi (the Windows norm), then this will equate to 21.33 pixels. For reference, this sentence is specified at 21.33 pixels. With the same parameters, a (hypothetically) good Mac CSS implementation would see it at 16 pixels, like this sentence. In any case, the object below maintains |
| 16:01 | <famicom> | proportionality with the text, regardless of font size or platform, because the height and width of the object are specified in em units as well. Change your font size and observe. Cool huh? [What? You say it doesn't work? Well of course not - there are no complete CSS implementations yet! Do complain.] |
| 16:02 | <famicom> | ^^ so no, it's not 16px |
| 16:03 | <TabAtkins> | ...what? Why would 12-point measure 16 points? |
| 16:04 | <TabAtkins> | 12pt equals 16px, maybe you're confusing yourself that way? |
| 16:04 | <TabAtkins> | Note that the pt to px conversion has no relation to your screen dpi. It's a fixed 3:4 ratio. |
| 16:05 | <nox> | smaug____: Step 9 looks redundant though. |
| 16:05 | <TabAtkins> | It sounds like you're quoting from something, and that something sounds old. |
| 16:05 | <nox> | smaug____: Shouldn't replacing the data in step 8 cover it? |
| 16:07 | <smaug____> | nox: replace puts offset to different place |
| 16:07 | <smaug____> | it uses offset + count |
| 16:07 | <nox> | smaug____: "For each range whose start node is node and start offset is greater than offset but less than or equal to offset plus count, set its start offset to offset." |
| 16:07 | <smaug____> | hmm, let me read again, I was looking startoffset |
| 16:07 | <nox> | It can't be greater than offset plus count, because offset plus count is the length of the Text node. |
| 16:08 | <smaug____> | "For each range whose end node is node and end offset is greater than offset but less than or equal to offset plus count, set its end offset to offset" |
| 16:08 | <nox> | Yes, it's the same thing for start and end offsets. |
| 16:08 | <famicom> | TabAtkins, https://www.w3.org/TR/REC-CSS1-961217#length-units |
| 16:08 | <smaug____> | so yes, 9 looks redundant |
| 16:09 | <TabAtkins> | ...omigod. Are you SERIOUSLY quoting CSS1, a *20-year old* document, at me? |
| 16:09 | <famicom> | http://lists.w3.org/Archives/Public/www-style/msg08095.html |
| 16:10 | <famicom> | TabAtkins, yes i am |
| 16:10 | <TabAtkins> | Why |
| 16:10 | <famicom> | because untill further notice that is the *standard* |
| 16:10 | <famicom> | An <absolute-size> keyword is an index to a table of font sizes computed and kept by the UA. Possible values are: [ xx-small | x-small | small | medium | large | x-large | xx-large ]. On a computer screen a scaling factor of 1.5 is suggested between adjacent indexes; if the 'medium' font is 10pt, the 'large' font could be 15pt. Different media may need different scaling factors. Also, the UA should take the quality and |
| 16:10 | <famicom> | availability of fonts into account when computing the table. The table may be different from one font family to another. |
| 16:10 | <TabAtkins> | lololol quit trolling |
| 16:10 | <famicom> | im dead serious, could you please state where it was redefined? |
| 16:11 | <TabAtkins> | No, I'm done. Muting you if you're gonna be like this. |
| 16:11 | <famicom> | ? |
| 16:12 | <famicom> | look. im fine with the statement that medium fontsize equals 16px, happy even. |
| 16:12 | <famicom> | but i do need it written down and set in stone somewhere |
| 16:23 | <nox> | famicom: What was redefined? |
| 16:23 | <famicom> | https://www.w3.org/TR/REC-CSS1-961217#length-units <<< this apparently |
| 16:24 | <nox> | https://drafts.csswg.org/css-values/#lengths |
| 16:26 | <nox> | pt points 1pt = 1/72th of 1in |
| 16:26 | <nox> | px pixels 1px = 1/96th of 1in |
| 16:26 | <nox> | 3:4 ratio, as TabAtkins said. |
| 16:29 | <SimonSapin> | yes, CSS1 was redefined. 19 years ago. https://www.w3.org/TR/WD-CSS2-971104/cover.html |
| 16:29 | <nox> | I'm glad I'm at least older than CSS. |
| 16:33 | <TabAtkins> | nox: There are webdevs entering the job market who can't say that, which feels CRAZY. |
| 16:33 | <nox> | Well I'm glad I'm not a webdev either, so there is that. :P |
| 17:04 | <famicom> | SimonSapin, https://www.w3.org/TR/WD-CSS2-971104/fonts.html#propdef-font-size |
| 17:05 | <famicom> | On a computer screen a scaling factor of 1.5 is suggested between adjacent indexes; if the 'medium' font is 10pt, the 'large' font could be 15pt. Different media may need different scaling factors. Also, the UA should take the quality and availability of fonts into account when computing the table. The table may be different from one font family to another. |
| 17:05 | <famicom> | that's all it says :/ |
| 17:05 | <SimonSapin> | "could", "should", "may" |
| 17:05 | <SimonSapin> | and this one has been redefined many times as well |
| 17:06 | <nox> | famicom: Did you see that the ratio between pt and px is fixed, at least? |
| 17:06 | <famicom> | yeah, 1.5 |
| 17:06 | <nox> | What? No. |
| 17:07 | <nox> | 3:4. |
| 17:07 | <famicom> | hold on, let me review |
| 17:13 | <famicom> | The relation between the absolute units is as follows: 1in = 2.54cm = 25.4mm = 72pt = 6pc |
| 17:14 | <nox> | famicom: Did you read the link I pasted? |
| 17:14 | <famicom> | In the past, CSS required that implementations display absolute units correctly even on computer screens. But as the number of incorrect implementations outnumbered correct ones and the situation didn't seem to improve, CSS abandoned that requirement in 2011. Currently, absolute units must work correctly only on printed output and on high-resolution devices. |
| 17:14 | <famicom> | The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like an e-book reader? The px is thus not defined as a constant length, but as something that |
| 17:14 | <famicom> | depends on the type of device and its typical use. |
| 17:14 | <famicom> | yeah i am |
| 17:14 | <nox> | https://drafts.csswg.org/css-values/#absolute-lengths |
| 17:15 | <famicom> | The reference pixel |
| 17:15 | <famicom> | is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). |
| 17:15 | <famicom> | The image below illustrates the effect of viewing distance on the size of a reference pixel: a reading distance of 71 cm (28 inches) results in a reference pixel of 0.26 mm, while a reading distance of 3.5 m (12 feet) results in a reference pixel of 1.3 mm. |
| 17:15 | <nox> | I'm starting to see why TabAtkins just stopped reading you. |
| 17:16 | <nox> | Why are you pasting walls of text when I pointed you to a neatly-typeset table that shows the exact relation between px and pt? |
| 17:33 | <famicom> | because i have no idea where those numbers came from, meaning they're informative while i NEED normative references |
| 17:33 | <famicom> | which is a huge distinction |
| 17:35 | <famicom> | either way, it seems that this is lost on whatwg members |
| 17:35 | <annevk> | Look, if you don't think anything but CSS1 is normative, why even hang out here? WHATWG changes multiple standards on a daily basis and only considers the latest normative... So if you're looking for theoretical arguments, this might not be your place |
| 17:35 | <annevk> | For starters, you might consider our channel topic |
| 17:36 | <famicom> | look, as far as i'm concerned you have rather little credibillity to begin with. |
| 17:37 | <jgraham> | Ah, so this conversation has gone from "dead parrot" to "argument clinic" |
| 17:37 | <famicom> | and i already got the answer i needed, there's no machine readable spec |
| 17:38 | Ms2ger | whacks jgraham over the head |
| 17:38 | <Ms2ger> | "whaaa" |
| 17:40 | <famicom> | quite frankly, if you just had the damn decency to produce a single diffable schema, i wouldnt have had to ask these pointless questions to begin with. |
| 17:42 | <famicom> | either way, you all seem to be taking the standardization process far too lightly |
| 17:42 | <annevk> | You're welcome to produce a schema |
| 17:43 | <annevk> | We gave up schemas being useful long ago |
| 17:43 | <famicom> | the reason being? |
| 17:43 | <famicom> | i take it you've never had the displeasure of working with soap or xslt |
| 17:44 | <annevk> | famicom: https://hsivonen.fi/thesis/html5-conformance-checker has some details |
| 17:44 | <famicom> | yeah, the guy who wrote validator.nu |
| 17:45 | <famicom> | except his schematron and rng schemas arent versioned |
| 17:45 | <annevk> | Neither is the standard |
| 17:46 | <TabAtkins> | Man, thinking CSS1 is the current definitive reference is so far from the "WHATWG doesn't take things seriously enough" argument that, wow. I mean, CSS2 was Rec in 1998, 2.1 in 2011. I'm not sure what level of "standardization" is being looked for here, but nobody in the web platform is looking to provide it. |
| 17:47 | <famicom> | well what are you looking to provide then?? |
| 17:48 | <annevk> | famicom: https://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F |
| 17:48 | <famicom> | and what on god greens earth are the ua vendors implementing |
| 17:49 | <annevk> | The standards with the green stylesheets, when they exist |
| 17:52 | <famicom> | standards for what, implemented by whom? |
| 17:52 | <famicom> | seriously, a single up to date list of single page documents would suffice |
| 17:53 | <famicom> | at this point it seems like the only way to be sure of implementation details is to mine the actual sourcecode of major rendering engines. |
| 17:53 | <jgraham> | Weirdly this is the point in history at which that is *least* true |
| 17:54 | <annevk> | famicom: like https://platform.html5.org/? |
| 17:56 | <famicom> | "HTML5 Please recommends as ready to use" |
| 17:57 | <famicom> | you are aware that by using popular implementations as the main reference you're just describing the situation, as-is |
| 17:59 | <famicom> | don't any of you remember the IE6 box model |
| 18:00 | <famicom> | by your reasoning, that would now be the "law of the land" |
| 18:00 | <TabAtkins> | Who are you, and what is the context of all this bizarre questioning and hostility? |
| 18:01 | <famicom> | about a year of tracking this nonsense on mailing lists and using those godawful broken tools you produce |
| 18:01 | <annevk> | famicom: indeed, most of us agree that the CSS WG back then should have made different decisions around quirks/standards mode and such |
| 18:02 | <Hixie> | man, it's been 18 years that i've been in standards and it's still the same discussions |
| 18:02 | <famicom> | you do realize that docbook is more stable more mature than that junk you wrote right? |
| 18:02 | <famicom> | sorry hixie |
| 18:02 | <jgraham> | Hixie: To be fair this discussion seems to have appeared through a wormhole from 2007 |
| 18:02 | famicom | humbly apologizes |
| 18:02 | <Hixie> | famicom: how many people write docbook? |
| 18:03 | <famicom> | anyone involved with OSS documentation? |
| 18:03 | <Hixie> | how many people write html? |
| 18:03 | <famicom> | how many people write useful html? |
| 18:04 | <nox> | Nice. |
| 18:04 | <Hixie> | well since docbook is pretty much exclusively used as an authoring format for future conversion to html, i'm gonna go with "more than docbook" |
| 18:04 | <famicom> | what about xmlspec |
| 18:04 | <famicom> | anyone remember that? |
| 18:04 | <nox> | famicom: Are you arguing that IE6 box model happened because of lack of spec? |
| 18:05 | <Hixie> | lack of test suite, more likely |
| 18:05 | <famicom> | nox, ie6 was a wilful violation |
| 18:05 | <famicom> | and led to an awful amount of ambiguety |
| 18:06 | <Hixie> | anyway, what's the argument here? famicom: do you have a proposal for how to change something? |
| 18:06 | <nox> | And how does a diffable spec avoid that, if any big UA decides to do yet another wilful violation? |
| 18:06 | <famicom> | Hixie, no, i just want a single machine readable standard |
| 18:06 | <Hixie> | define "machine readable" |
| 18:07 | <famicom> | xsd |
| 18:07 | <famicom> | dtd |
| 18:07 | <nox> | What does that change? |
| 18:07 | <famicom> | on a fixed publishing point |
| 18:07 | <nox> | Do you only use programming languages with such specs, btw? |
| 18:07 | <Hixie> | oh you want a schema that defines when a byte stream is a valid conforming representation and when it's not? |
| 18:07 | <famicom> | yup |
| 18:07 | <Hixie> | that's easy |
| 18:08 | <famicom> | i got 12 thousand files that need to be converted into html views |
| 18:08 | <Hixie> | new schema language: "HTML Schema Language". Has one element, "HTML". A byte stream matches HTML if it conforms to the HTML spec. |
| 18:08 | <Hixie> | new schema for the HTML spec: "HTML" |
| 18:08 | <famicom> | i know, i read the damn thing |
| 18:08 | <Hixie> | done and done. |
| 18:08 | <Hixie> | next question please |
| 18:09 | <famicom> | so Hixie does this mean my beloved <blink> tag is back? |
| 18:09 | <famicom> | :D |
| 18:10 | <nox> | XSD describes XML dialects, DTD describes XML and SGML. HTML is neither now. |
| 18:10 | <famicom> | schemas can be used for instance generation |
| 18:10 | <Hixie> | not sure how what i said has anything to do with blink. |
| 18:10 | <famicom> | as well as validation |
| 18:10 | <nox> | famicom: For XML and SGML, yes. |
| 18:11 | <nox> | famicom: What do you do about HTML being neither XML nor SGML? |
| 18:11 | <famicom> | figure out what it is? |
| 18:11 | <nox> | It's HTML. |
| 18:11 | <famicom> | well of all places i shouldnt be having this conversation here |
| 18:12 | <nox> | How do you do validate C code? |
| 18:12 | <Hixie> | how do you validate SGML DTDs |
| 18:12 | <famicom> | nox |
| 18:12 | <famicom> | ISO/IEC 9899 |
| 18:12 | <nox> | Is that machine-readable? |
| 18:13 | <famicom> | this is over your head nox, please don't try |
| 18:13 | <famicom> | but yeah, it is tested for conformance |
| 18:13 | <nox> | I know I'm only 167cm tall, but I still can do all the rollercoasters I want at Disney, |
| 18:13 | <nox> | so I think I can try that. |
| 18:14 | <famicom> | http://www.peren.com/pages/cvsa_set.htm |
| 18:14 | <nox> | Code is validated through feeding it to something that implements whatever constraints are stated in the spec. |
| 18:14 | <nox> | Same as how HTML validators work. |
| 18:14 | <famicom> | yeah, except the current spec depends on the current implementation. |
| 18:15 | <famicom> | which im sure is intentional |
| 18:15 | <famicom> | but not how standards work |
| 18:15 | <nox> | Yes, because doing otherwise never worked. |
| 18:15 | <nox> | And the current spec depends on the consensus of current implementations, plural. |
| 18:15 | <famicom> | THEN CALL IT AN IMPLEMENTATION REFERENCE, NOT A STANDARD |
| 18:15 | <nox> | It's not an implementation. |
| 18:16 | <TabAtkins> | Okay, so your context is that you have a bunch of files in subs other format, and you want to convert them to HTML. |
| 18:16 | <nox> | Sorry, parsed that as reference implementation because caps are difficult to read. |
| 18:16 | <Hixie> | wait what |
| 18:16 | <Hixie> | what's the difference between "IMPLEMENTATION REFERENCE" and "STANDARD" |
| 18:16 | <nox> | The irony is having this discussion through IRC, |
| 18:16 | <famicom> | sigh |
| 18:17 | <Hixie> | the HTML spec is a standard implementation reference and a standard document conformance reference |
| 18:17 | <nox> | which is definitely not implementation-driven, right? |
| 18:17 | <famicom> | implementations arent always fully compliant |
| 18:17 | <famicom> | ie, an unreliable source |
| 18:17 | <Hixie> | sgml implementations aren't always compliant either |
| 18:17 | <nox> | What do you do when 70% of the market is an non-compliant implementation? |
| 18:18 | <Hixie> | that's just a truth about software |
| 18:18 | <famicom> | nox, avoid further ambiguety |
| 18:18 | <nox> | How do you do that without changing the spec? |
| 18:19 | <famicom> | incrementally |
| 18:19 | <nox> | So, like HTML now? |
| 18:19 | <famicom> | no, because at some point you need a frozen featureset |
| 18:20 | <famicom> | which you don't provide |
| 18:20 | <nox> | Why, if that's not what's implemented? |
| 18:21 | <famicom> | sigh, it's still better than having some MSFT brogrammers dictate the schedule and features |
| 18:21 | <nox> | What do you do if you have a frozen featureset, and the biggest UA suddenly change directions and make a backwards-incompatible change? |
| 18:21 | <famicom> | then they're wrong |
| 18:21 | <nox> | People don't care. And it's IE6 box model time again. |
| 18:22 | <famicom> | yeah, but now you just give up and proclaim IE6's boxmodel as the new "one true way" |
| 18:22 | <famicom> | which is cowardice |
| 18:22 | <TabAtkins> | famicom: Since you're doing a mass HTML conversion, I recommend looking up basic HTML tutorials, and only checking the HTML spec if there are details you can't find otherwise. You mostly don't need to worry about it if you're just doing a cross-format conversion. |
| 18:22 | <nox> | Cowardice? Wtf does that have anything to do with this discussing? |
| 18:22 | <annevk> | you do realize box-sizing basically standardized the IE6 box model and then some? |
| 18:23 | <Hixie> | famicom: we do have a frozen featureset |
| 18:23 | <nox> | And as you guessed earlier, I'm not fit enough to be a brogrammer, btw. |
| 18:23 | <TabAtkins> | When I was a wee webdev, I learned from HTMLDog.com, but CSSTricks has decent stuff too, and there's a lot of other resources these days that I don't know about. |
| 18:23 | <annevk> | and there's loads of people that prefer using box-sizing to get something like the IE6 box model |
| 18:23 | <Domenic> | this is ... amazing |
| 18:23 | <Hixie> | famicom: every single time the spec is revised, it's a new version |
| 18:23 | <nox> | TabAtkins: Should just check w3schools, right? |
| 18:23 | <famicom> | Hixie, yeah, and anounced where? |
| 18:23 | <TabAtkins> | nox: Please, we're trying to help. Dont' troll. |
| 18:23 | <Domenic> | TabAtkins: html5 goodies was my jam. I wonder if that's still around. It had a grotesque large-headed long-necked illustration of the author as its mascot. |
| 18:23 | <nox> | TabAtkins: I disagree with you conflating jokes and trolls, but ok. :( |
| 18:23 | <Hixie> | famicom: since it happens multiple times a day, it doesn't really need to be announced. but you can subscribe to the github notifications if you want an announcement. |
| 18:23 | <famicom> | and twitter isn't a valid or reliable source |
| 18:24 | <TabAtkins> | (nox: I was joking, it's cool. ^_^) |
| 18:24 | <nox> | TabAtkins: Ok. :) |
| 18:24 | <annevk> | TabAtkins: htmldog <3 |
| 18:24 | <famicom> | seriously, github? |
| 18:24 | <annevk> | TabAtkins: although I learned from a set of books I bought |
| 18:24 | <Domenic> | zomg amazing https://web.archive.org/web/19990224005512/http://www.htmlgoodies.com/ |
| 18:24 | <famicom> | god, why don't you just go full circle and use hosting from myspace |
| 18:25 | <TabAtkins> | famicom: The least useful thing you could do to help in your project is troll a spec-dev chatroom throwing a lot of hostility from an early-2000s era of theoretical spec design. |
| 18:25 | <nox> | famicom: How does the hosting platform matter? |
| 18:25 | <famicom> | TabAtkins, lol |
| 18:25 | <Hixie> | famicom: you can copy the spec and put it wherever you like |
| 18:25 | <famicom> | Hixie, what is the authoritative point of reference |
| 18:25 | <nox> | famicom: An ISO spec behind a CHF paywall is way better, right? |
| 18:25 | <Domenic> | This guy really is from 1997, he doesn't use GitHub or Twitter... |
| 18:25 | <Hixie> | famicom: html.spec.whatwg.org |
| 18:26 | <famicom> | Hixie, where are updates announced |
| 18:26 | <Hixie> | but that's just a web site |
| 18:26 | <TabAtkins> | Some of us might be willing to spend time teaching you the basics of how spec design has evolved in the last two decades of experience, but that's not going to be helpful fo ryou rimmediate project, and your hostility at the moment is making it very unlikely that we'll be willing to help. |
| 18:26 | <famicom> | Hixie, where is the source |
| 18:26 | <Hixie> | famicom: they're not. they happen literally daily. |
| 18:26 | <Hixie> | the source? |
| 18:26 | <Hixie> | source of what |
| 18:26 | <famicom> | html.spec.whatwg.org |
| 18:26 | <nox> | famicom: https://github.com/whatwg/html |
| 18:26 | <TabAtkins> | Hixie: Well, they're announced on Twitter, and you can always check the VC history. |
| 18:26 | <famicom> | or do i just need to scrape it |
| 18:26 | <Hixie> | https://html.spec.whatwg.org/index.html |
| 18:26 | <nox> | famicom: It's generated through a tool written in Pascal. |
| 18:26 | <famicom> | got it |
| 18:26 | <famicom> | thanks Hixie |
| 18:26 | <Hixie> | i'm not sure i really understand what you're asking |
| 18:26 | <nox> | That should make you feel at home like it's 1990 again. |
| 18:26 | <famicom> | you're always the voice of reason |
| 18:27 | <famicom> | nox, TabAtkins go back to preschool you toddlers |
| 18:27 | <Domenic> | I think we need some moderation here |
| 18:27 | <nox> | I didn't know English in preschool. |
| 18:27 | <annevk> | Hixie: /index.html 404s at the moment, just / is better |
| 18:27 | <nox> | Domenic: Sorry. :( |
| 18:27 | <TabAtkins> | Yuuup, mod time for the troll now. |
| 18:27 | <Hixie> | annevk: lol k |
| 18:27 | <Hixie> | famicom: hey you can ask questions about the process but stay polite please |
| 18:28 | <famicom> | yeah, will do |
| 18:30 | <jwalden> | annevk: egad all those internal method definitions/overrides in https://github.com/annevk/html-cross-origin-objects are horrific :-) |
| 18:30 | <annevk> | jwalden: yeah, I have no idea what I'm doing |
| 18:30 | <jwalden> | lol |
| 18:30 | <jwalden> | wcgr |
| 18:30 | <jwalden> | ("what could go wrong") |
| 18:30 | <annevk> | I'm sure bholley will tell me |
| 18:31 | <annevk> | But who knows |
| 18:32 | jwalden | supposes he should take the time to grok this a bit now, beyond just the cursory skim |
| 18:36 | <annevk> | I have half a plan of writing some kind of introductory blog post |
| 18:36 | <jwalden> | annevk: speaking of blog posts, I liked your most recent one about app security model nonsense :-) |
| 18:38 | <jwalden> | selling JMAP or similar to all IMAP implementation seems pretty hard, unfortunately :-( |
| 18:38 | <jwalden> | maybe even impossible |
| 18:38 | <famicom> | unlikely if anything |
| 18:39 | <famicom> | it isn't mature, it doesnt "solve" anything |
| 18:39 | <famicom> | and email is literally the last set of protocols you want to get involved in |
| 18:41 | <annevk> | jwalden: yeah, but I'm also not convinced we really need IMAP to succeed |
| 18:41 | <famicom> | maar daar kom je wel achter zodra jeje eerste MDA hebt geprovisioneerd |
| 18:42 | <jwalden> | annevk: everyone would just use mobile webmail sites then, somehow? |
| 18:43 | <Domenic> | jwalden: that seems uncontroversial :). The question I think is whether you need to be able to do IMAP mail processing on the client or just on the server |
| 18:43 | <annevk> | jwalden: yeah, we should have offered a competitive messaging client too of sorts, to offset Whatsapp not being on the web |
| 18:44 | <jwalden> | essentially not owning a phone (let alone a smart one), I certainly can't speak about the messaging ecosystem or its needs or the need for such things at all :-) |
| 18:45 | <annevk> | heh |
| 18:46 | <annevk> | afk |
| 18:46 | <famicom> | jwalden, youre not missing out |
| 18:46 | <jwalden> | :-D |
| 18:46 | <famicom> | they recently repurposed email as "conversations" |
| 18:46 | <famicom> | which is really interesting when receiving snmp reports |
| 18:46 | <jwalden> | however, I *am* available for any and all lawn-related speaking arrangements |
| 18:47 | <famicom> | yeah well, im going to play star citizen |
| 18:47 | <famicom> | sorry to bother yall |
| 18:47 | <famicom> | and Hixie you are god |
| 18:47 | <famicom> | ^h^h^h last remaining grownup |
| 18:47 | <jwalden> | there are grownups here? |
| 18:48 | <famicom> | at least some who remember that there was an industry before them |
| 18:49 | <famicom> | insteda of just teenagers posing as "ux specialists" or "frontend developers" |
| 18:50 | <jwalden> | oh, we're all just posers, how else to explain the architecture of the web as we know it? :-) |
| 18:50 | <famicom> | simple |
| 18:50 | <famicom> | a series of tubes |
| 18:51 | <famicom> | it's not a big dump truck |
| 18:52 | <famicom> | but seriously, it's like september 1993 all over again |
| 18:52 | <famicom> | but this time, instead of AOL, it's these damn smartphones, and this time, rather than users the newbies think they're developers |
| 18:53 | <jsbell> | "uphill both ways in the snow..." |
| 18:54 | <famicom> | laugh all you want, but slowly a part of me is dying inside |
| 18:55 | <jwalden> | when the choice is between dying inside and laughing, I choose the latter (or at worst choose both) |
| 18:56 | <jwalden> | recommended for general sanity around here |
| 18:56 | <TabAtkins> | annevk: Jeezus christ, can we ban this person? Straight trolling after a clear warning. |
| 18:56 | <famicom> | jwalden, cant fight progress |
| 18:56 | <famicom> | but you can patch it out! |
| 19:05 | <nox> | famicom: Stop assuming things about people you speak with and explain yourself better without using derogatory terms and maybe it will go better. |
| 20:17 | <sj13> | I am a beginner and would like to contribute. I found this issue: https://github.com/whatwg/html/issues/535, however, I cannot pin-point the exact file where the change needs to be made. Can someone help? |
| 20:33 | <TabAtkins> | sj13: Check the README at https://github.com/whatwg/html, it tells you which file to edit to make changes. |
| 20:50 | <annevk> | TabAtkins: not sure I can, I did use /ignore |
| 20:58 | <nox> | annevk: Blabla not grownups blabla Web users not developers |
| 21:00 | <annevk> | nox: heh, thinking about it, they never read https://annevankesteren.nl/2007/04/html-red-pill I guess |
| 21:01 | <nox> | annevk: It's also weirdly fun to me because I don't author any HTML. |
| 21:02 | <nox> | To protect myself from the insanity, I would rather go the cyclone's eye and just implement it. :P |
| 21:03 | <annevk> | Well, let me know in five years how that worked out for you |
| 21:04 | <nox> | annevk: Probably deaf over the terrifying sounds of the eyewall. |
| 21:04 | <annevk> | My door is full of logic, but I lost it |
| 21:05 | <nox> | annevk: There is an anime this season where you can literally lose your logic card. |
| 21:05 | <nox> | You can't be a logicalist anymore if you lose it. |
| 21:05 | <annevk> | I see, is there a way to get it back? |
| 21:06 | <nox> | The hero regains his own in the first episode through unknown means but that seems like a one-time thing. |
| 21:06 | <nox> | I guess you'll never find back your door. |
| 21:17 | <aklein> | annevk: re https://github.com/annevk/html-cross-origin-objects, are various ES6 symbols on your radar? For example, @@toStringTag, @@hasInstance, @@isConcatSpreadable. It would be nice to define the behavior of all of these in a cross-origin object |
| 21:47 | <gsnedders> | I… I'm so confused by earlier. |
| 21:47 | <jgraham> | The concept of past, or something more specific? |
| 21:48 | <gsnedders> | The discussion in here earlier. |
| 21:49 | <jgraham> | It seemed like a totally normal discussion for this channel |
| 21:50 | <jgraham> | Just one that you would have expected to happen about a decade ago |
| 21:57 | <TabAtkins> | Yeah, that was the sort of thing I got used when I joined the channel, like, 7 or 8 years ago. |
| 21:58 | <TabAtkins> | *used to |
| 21:59 | <gsnedders> | it seemed even further back than when I joined a decade ago. |
| 21:59 | <gsnedders> | given the references to CSS 1 |
| 22:02 | <TabAtkins> | That's what really threw me. Some people are weird and unreasonable about the definition of "stable", but by any definition I've *ever* heard, Recs (like 2.1) qualify. I have absolutely no idea how someone gets themselves twisted into the idea that CSS*1* is the only valid standard so far. |
| 22:03 | <gsnedders> | like, yes, otherwise it was a fairly 2006 argument |
| 22:04 | <Hixie> | CSS1 in particular was pretty terrible |
| 22:09 | <TabAtkins> | Maybe XSLT has a previously-undiscovered ability to transform *through time*, and we're seeing the first results of that. |
| 22:09 | <gsnedders> | TabAtkins: hmm, didn't realise Turing Machine were time machines. |
| 22:10 | <TabAtkins> | IT'S RIGHT THERE IN THE ACRONYM |
| 22:14 | <gsnedders> | THAT'S SO OBVIOUS, WHY DID I NEVER REALISE?! |
| 22:44 | <astearns> | which acronym? the one for eXtenstible Simultaneity Layering Transformations? |
| 22:45 | <TabAtkins> | You've found the four words in one acronym that enlightens us to the time cube! |
| 22:45 | <TabAtkins> | We are no longer educated stupid! |