| 00:53 | <cabanier> | TabAtkins: ping |
| 00:54 | <cabanier> | TabAtkins: bikeshed is reporting "ImportError: No module named six" |
| 00:54 | <cabanier> | https://www.irccloud.com/pastebin/zrm5b7sH |
| 00:54 | <cabanier> | TabAtkins: Any ideas? |
| 00:54 | <cabanier> | TabAtkins: It's on mac |
| 00:55 | <TabAtkins> | let me go see! |
| 01:00 | <caitp> | making python do anything right is kind of amazing |
| 01:03 | <cabanier> | TabAtkins: just got a new mac so it could be that something is in a bad state |
| 01:04 | <TabAtkins> | Argh, having trouble entering my chroot now, probably caused by the most recent update to chromeos |
| 01:04 | <TabAtkins> | And yeah, I haven't touched that part of the code. You followed the install instructions? |
| 01:04 | <TabAtkins> | Possible that six wasn't part of the install instructions, but it worked because everyone already had it on mac or something. |
| 01:05 | <cabanier> | TabAtkins: yes. https://github.com/tabatkins/bikeshed/blob/master/docs/install.md |
| 01:05 | <SimonSapin> | TabAtkins: six should just come as a dependency when you install html5lib |
| 01:06 | <TabAtkins> | Yeah, it should. Weird that it's not. |
| 01:06 | <SimonSapin> | the state of Python on OS X makes me sad |
| 01:06 | <cabanier> | I did "sudo port install py27-six" |
| 01:06 | <cabanier> | now it works :-) |
| 01:07 | <caitp> | it's not that python is bad on osx, it's just bad everywhere |
| 01:07 | <caitp> | this is why nobody likes writing python :( |
| 01:07 | <TabAtkins> | caitp: Except, the exact opposite. |
| 01:07 | <TabAtkins> | cabanier: I'll amend the docs. |
| 01:07 | <SimonSapin> | caitp: disagree |
| 01:07 | <cabanier> | TabAtkins: thanks! |
| 01:08 | <caitp> | dart has a decent package manager, go sort of has something vaguely like a package manager, node has a pretty great package manager |
| 01:08 | <caitp> | all 3 make that stuff so much less of a headache |
| 01:08 | <TabAtkins> | Python has a decent package manager too. |
| 01:08 | <TabAtkins> | On Linux. |
| 01:09 | <caitp> | it really doesn't, I've been using python on linux :( |
| 01:09 | <TabAtkins> | So have I. |
| 01:13 | <caitp> | there are always going to be a few people who are really into whatever language, even if it's haskell or rust |
| 01:14 | <TabAtkins> | I'm just saying, I've never had problems with pip on linux. |
| 01:14 | <TabAtkins> | And I've done a year of off-and-on heavy dev on Bikeshed. |
| 01:18 | <caitp> | i'm just saying, the barrier to entry and the maintenance headache for this stuff should rightfully be a lot less than it is |
| 01:18 | <caitp> | these are solved problems in general |
| 01:19 | <TabAtkins> | Maybe so, but I haven't seen these problems you're alluding to. ^_^ |
| 01:20 | <caitp> | must be nice :> i never saw them with mozilla's python stuff, but i see them with every flask app ive ever seen |
| 01:21 | <caitp> | or any non-easy_install library that isnt dealt with by someone else |
| 01:21 | <caitp> | anything that wants to use venv |
| 01:50 | <SimonSapin> | "these are solved problems in general" [citation needed] |
| 02:22 | <jdaggett_> | annevk: ping |
| 08:01 | <annevk> | jdaggett_: hey |
| 08:03 | <jdaggett_> | annevk: had a design question for you but ended up talking about it with mike smith instead! :) |
| 08:03 | <jdaggett_> | annevk: you're in london these days? |
| 08:03 | <annevk> | jdaggett_: Zürich |
| 08:03 | <jdaggett_> | sweet! |
| 08:04 | <jdaggett_> | annevk: have you glanced over the font loading api recently? http://dev.w3.org/csswg/css-font-loading |
| 08:05 | <jdaggett_> | annevk: wondering if it might be better to structure the spec so that the algorithms were grouped together more clearly |
| 08:06 | <annevk> | That's up to you guys really |
| 08:06 | <annevk> | The only thing I'd try to make sure of is that algorithms that are also used by CSS syntax (not the API) are separate so they can be referenced and used from multiple places |
| 08:09 | <jdaggett_> | annevk: well, there's "fudge it" language -- User agents can initiate font loads on their own, whenever they determine that a given font face is necessary to render something on the page. When this happens, they must act as if they had called the corresponding FontFace’s load() method described here. |
| 08:10 | <jdaggett_> | :P |
| 08:11 | <annevk> | Seems reasonable I guess, although that language does not quite make it clear whether or not the load() method can be overridden by web developers |
| 08:12 | <jdaggett_> | annevk: hmmm, interesting |
| 08:13 | <annevk> | jgraham: I find it easier to have a separate algorithm that load() invokes and that the other CSS spec can invoke |
| 08:13 | <annevk> | jdaggett_: ^ |
| 08:13 | <annevk> | jdaggett_: but you can also talk about the object's initial property value; XMLHttpRequest does something like that for using JSON.parse() |
| 08:13 | <jdaggett_> | yeah, that sounds like a better thing |
| 08:14 | <jdaggett_> | annevk: btw, if a spec says (1) fire a blahblah event at object X (2) fulfill promise foobar |
| 08:15 | <jdaggett_> | annevk: does that imply anything about the order of the event handler and resolve methods are executed? |
| 08:16 | <annevk> | jgraham: if that is all it says the event would fire immediately and the promise callbacks would be run later (before end-of-task) |
| 08:16 | <annevk> | (or at end-of-task, depends on how you view things I guess) |
| 08:16 | <jdaggett_> | mmm, ok |
| 08:31 | jgraham | still isn't jdaggett_ :p |
| 08:32 | <jdaggett_> | heh |
| 08:32 | <jdaggett_> | nor should you ever want to be... |
| 08:56 | <annevk> | oh sorry :/ |
| 09:51 | <JakeA> | annevk: I don't see the relevance of https://github.com/slightlyoff/ServiceWorker/issues/518#issuecomment-60060589 - wrong ticket? |
| 09:52 | <annevk> | JakeA: I don't want ServiceWorkerClient as an object per 512 / 511 |
| 09:53 | <JakeA> | annevk: ahh, but ServiceWorkerClients is different |
| 09:53 | <annevk> | JakeA: oh, it's all of them |
| 09:53 | <annevk> | JakeA: deleted comment |
| 09:53 | <JakeA> | JakeA: it's where the getters for the clients, and things like reloadAll (will) live |
| 09:54 | <annevk> | JakeA: still unclear how that makes sense for workers though |
| 09:54 | <annevk> | JakeA: reload that is |
| 09:55 | <JakeA> | annevk: yeah, reloadAll has more problems than just that. It's a good feature, but needs way more thought, that's why I removed it. |
| 10:00 | <annevk> | JakeA: hmm, perhaps a dedicated worker cannot be a client due to its API |
| 10:01 | <annevk> | JakeA: a dedicated worker assumes it only has a relationship with a window |
| 10:01 | <annevk> | JakeA: I guess it could still talk to Fetch directly, with a capability given by the Window/Document |
| 10:29 | <JakeA> | annevk: which bit of its API gets in the way? |
| 10:30 | <annevk> | JakeA: a dedicated worker assumes it's associated with a single port |
| 10:31 | <JakeA> | annevk: ah, so another env wouldn't be able to post messages to it? |
| 10:31 | <annevk> | JakeA: yeah, the logic doesn't really support that |
| 10:31 | <annevk> | JakeA: you'd effectively turn it into a shared worker at that point |
| 10:31 | <annevk> | afaict, anyway |
| 10:35 | <JakeA> | I'll continue assuming it's just windows & sharedworkers, we can add dedicated workers in if needed |
| 10:35 | <JakeA> | (I say 'continue', I'm just about to get onto it, so questions incoming) |
| 10:37 | <annevk> | Yeah, given the way the dedicated worker API works, that seems fine |
| 10:37 | <annevk> | We'll just have to learn to appreciate that there's not really any governing logic to these things |
| 10:43 | <annevk> | I missed http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/ I hope Jeff doesn't actually think the W3C enables those five things |
| 10:47 | <erlehmann> | annevk what i am worried about with workers is that clients need to send messages to them. since js is single threaded, wouldn't that mean that if a worker has a huge dataset to work on that dataset would have to be messaged to them and interface would freeze in the meantime? |
| 10:48 | <annevk> | erlehmann: workers run in a distinct thread |
| 10:49 | <erlehmann> | annevk yes, but the messaging of the huge dataset could prove problematic, wouldn't it? |
| 10:49 | <erlehmann> | like the communication of and from to the worker |
| 10:49 | <annevk> | erlehmann: depends on how it's done, if you can transfer rather it, you might be okay |
| 10:49 | <annevk> | s/rather// |
| 10:50 | <erlehmann> | data is copied, not shared |
| 10:50 | <erlehmann> | i have to benchmark this in real-world cases |
| 10:52 | <annevk> | erlehmann: no, you can actually transfer the data rather than copy it if you use an ArrayBuffer |
| 10:54 | <erlehmann> | ah |
| 10:54 | <erlehmann> | thx annevk |
| 11:43 | <annevk> | "Mark Day: the usual model is that W3C develops stuff; some of it is deemed mature enough to transition over to another, larger or better-trained body like IETF. To my memory it hasn't gone the other way around." |
| 11:43 | <annevk> | https://www.ietf.org/proceedings/44/44th-99mar-ietf-121.html |
| 11:47 | <annevk> | Yay, SSLv3 disabled: https://www.ssllabs.com/ssltest/analyze.html?d=annevankesteren.nl |
| 11:48 | <annevk> | whatwg.org still has some ways to go; server not updated yet I guess |
| 13:08 | <JakeA> | annevk: If I want to get the url of a client, is it "the client's global object's location's href"? |
| 13:09 | <annevk> | JakeA: it depends on the type of client |
| 13:09 | <annevk> | JakeA: we could ask Hixie to put an accessor on the environment settings object |
| 13:10 | <annevk> | JakeA: but e.g. if the global object is a Window, you want it's associated document's url. |
| 13:10 | <JakeA> | annevk: that would help. Although don't all types of client have a location? |
| 13:10 | <JakeA> | workers & windows have .location |
| 13:10 | <annevk> | JakeA: yes, but that's an API, not an underlying concept |
| 13:11 | <annevk> | JakeA: and e.g. for a Window would give the address of the active document, which might not be correct I suppose |
| 13:12 | <JakeA> | annevk: struggling to find the window concept |
| 13:13 | <JakeA> | or is it "browsing context"? |
| 13:13 | <annevk> | JakeA: it's global object |
| 13:13 | <annevk> | JakeA: a browsing context has a history, so that's not quite it |
| 13:14 | <annevk> | JakeA: I have the feeling Hixie could refactor it a bit more, though I understand why he would be hesitant about that |
| 13:19 | <JakeA> | annevk: so I'm at https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object, looking for a way to get the URL, I guess "global object" isn't it, because that only gives me APIs and not concepts. Base URL will (presumably) be affected by <base>, so that isn't what I want. Getting the url from the browsing context is messy when it |
| 13:19 | <JakeA> | comes to navigations and window.open |
| 13:20 | <JakeA> | thinking out loud, but struggling to get to a url. Am I at least thinking about it in the right way? |
| 13:20 | <JakeA> | Or have I discounted the right answer by mistake? |
| 13:22 | <annevk> | JakeA: it's fine to inspect objects |
| 13:22 | <annevk> | JakeA: the problem with Location is that if you look at the API, you'll find it returns the active document's url |
| 13:22 | <annevk> | JakeA: whereas here we should probably return global object's associated document's url |
| 13:23 | <annevk> | JakeA: also, we don't typically say return the value from location.href or some such, but rather just get at the value that API would return (though in this case that would be wrong) |
| 14:23 | <JakeA> | annevk: active document seems fine. It's the document in the history sequence that's currently in use right? |
| 14:24 | <JakeA> | annevk: or does it get broken by child browsing contexts and window.open? |
| 14:24 | <JakeA> | "broken" in terms of my intended use |
| 14:37 | <JakeA> | annevk: I've replaced client url with: <a href="https://fetch.spec.whatwg.org/#concept-request-client">client</a>'s <a href="https://html.spec.whatwg.org/multipage/webappapis.html#global-object">global object</a>'s <a href="https://html.spec.whatwg.org/multipage/browsers.html#location">location</a>'s underlying <a |
| 14:37 | <JakeA> | href="https://url.spec.whatwg.org/#concept-urlutils-url">URL</a>; |
| 14:39 | <JakeA> | I can farm this out to an algorithm section, "Get URL From Client" or whatever |
| 14:40 | <JakeA> | Yeah, I'll do that |
| 14:40 | JakeA | disconnects his thoughts from #whatwg for a moment |
| 14:57 | <annevk> | JakeA: that's not an actual thing though |
| 14:58 | <annevk> | JakeA: just file a bug on Hixie to attach such a thing to environment setting objects |
| 14:58 | <JakeA> | annevk: what isn't a thing? |
| 14:58 | <annevk> | "location's underlying URL" |
| 14:59 | <JakeA> | annevk: But location implements URLUtils, and that has the concept of a URL. Or can I not go from API to concept? |
| 15:00 | <annevk> | JakeA: as I said, location's url is the one from the active document, we don't want that here |
| 15:02 | <JakeA> | annevk: haven't figured out when that breaks. The active document is the currently used document in the history sequence, right? When isn't that what we want? Or does it get broken (from what I want) by child browsing contexts and window.open? |
| 15:02 | <annevk> | JakeA: because at that point it's a different document |
| 15:03 | <annevk> | JakeA: e.g. if you navigate from a.com to b.com, the active document changes, but we don't want the URL to change in that case |
| 15:03 | <annevk> | JakeA: that'd be pretty weird |
| 15:20 | <annevk> | JakeA: how does appcache have path-based security? |
| 15:27 | <JakeA> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25699 |
| 15:27 | <annevk> | JakeA: ah okay, is that actually implemented? |
| 15:29 | <JakeA> | annevk: nah, we've got someone assigned to do it, but not done yet |
| 15:29 | <annevk> | so maybe it's not a problem at all? |
| 15:30 | <JakeA> | I guess I could already take-over jsbin's 404 pages using appcache |
| 15:31 | <JakeA> | will add that to the issue |
| 15:35 | <JakeA> | annevk: visit https://jsbin.com/yisiju/quiet, then visit https://jsbin.com/blahblahwhatever |
| 15:37 | <annevk> | JakeA: why does it come back with " Remy smells of poo "? |
| 15:38 | <annevk> | oh I see |
| 15:38 | <JakeA> | annevk: I've taken over al 404s BY THE POWER OF APPCACHE |
| 15:38 | <annevk> | okay you that's bad |
| 15:39 | <JakeA> | annevk: yeah, mix this in with a bit of MITM and… well… appcache should have been https only |
| 15:40 | <annevk> | We were gonna disable appcache I think |
| 15:40 | <annevk> | I wonder why that hasn't happened yet |
| 15:40 | <JakeA> | annevk: Jonas said "as soon as serviceworker ships" |
| 15:57 | <Domenic> | JakeA: i bet you feel like one of those l33t "attackers" you hear so much about, now. |
| 15:59 | JakeA | goes off to pwn something |
| 16:00 | <jgraham> | JakeA: AIUI all you actually need to do is own evil.com. It's the web equivalent of having a secret base inside a volcano. |
| 16:02 | <boogy> | annevk: JakeA: e.g. if you navigate from http://a.com/ to http://b.com/, the active document changes, but we don't want the URL to change in that case <— Doesn't this break principles of showing appropriate content for the current url? Or is this some weirdness where only the canonical meta tag updates? |
| 16:04 | <JakeA> | annevk: also, if the user navigates, don't we want the url to change? |
| 16:05 | <JakeA> | (I think I'm hitting the spec writing learning curve) |
| 16:12 | <annevk> | boogy: I'm not sure what you're saying |
| 16:13 | <annevk> | JakeA: if the user navigates the global object changes as well, so you get a different place to postMessage to |
| 16:13 | <annevk> | JakeA: and the document changes |
| 16:13 | <annevk> | JakeA: as I said, Location is weird |
| 16:14 | <boogy> | annevk: what is the use-case where someone is navigating from domain.tld to domain2.tld without the url changing but the content changing? |
| 16:15 | <annevk> | boogy: the point is that the URL from domain.tld has not changed |
| 16:15 | <annevk> | boogy: so when we're talking with the content from domain.tld, we should not report the URL from some different content |
| 16:16 | <JakeA> | annevk: I guess this is why we considered navigation creating a new client and killing the old |
| 16:17 | <JakeA> | annevk: (by we I mean serviceworker client). Will work from home tomorrow so I can actually get this done. Today was mostly serviceworker support and meetings :( |
| 16:18 | <annevk> | JakeA: if I go to <a href=/b></a> from /a you'd expect /b to have its own Document (and therefore its own Window), but you wouldn't expect the client from /a to report /b |
| 16:19 | <annevk> | JakeA: and I don't think we want to make a client an actual browsing context with history and everything... though it would have been good if someone had thought about this while we created service workers |
| 16:20 | <boogy> | I'm not fully understanding the context here. Are you discussing the reporting as it relates to service workers? In my humble opinion, I very much would not expect content from /b to report as /a if that content produced a new document load. |
| 16:21 | <boogy> | as a web author, nor as an educated user. |
| 16:22 | <annevk> | I don't think there's actual disagreement, just not sufficient understanding about how self.location actually works |
| 16:26 | <boogy> | shouldn't it report the information most relevant to the document content? |
| 16:33 | <annevk> | boogy: it should do what it has always done so it doesn't break sites |
| 16:34 | <tantek> | annevk - any objection to me proposing to Art that WebAppsWG drop their outdated copy of Fullscreen, and simply instruct all dependent parties to reference the WHATWG living spec for Fullscreen? |
| 16:34 | <JakeA> | annevk: I need to get the url on navigate (to see which serviceworker registration to assign) and as a snapshot when we get clients (for getAll, and request.client). Doesn't this avoid the changing url issue? |
| 16:35 | <annevk> | tantek: yeah, I thought the CSS WG already decided as much |
| 16:37 | <tantek> | annevk - apparently we have to tell all the WGs |
| 16:37 | <Ms2ger> | Isn't a WG just a support forum? |
| 16:37 | <tantek> | Ms2ger - a very good question. |
| 16:38 | <annevk> | tantek: tell 'm |
| 16:38 | <tantek> | now that I'm co-chairing one ( Social Web WG ) I'm beginning to believe that it might be mostly a support forum for those who have ideas but don't actually build anything. |
| 16:39 | <tantek> | Ms2ger - WGs sometimes can also serve as honeypots for counter-productive individuals as well. |
| 16:40 | <annevk> | tantek: might want to reference http://lists.w3.org/Archives/Public/www-style/2014Oct/0295.html |
| 16:41 | <tantek> | annevk - thanks much. that's very helpful. |
| 16:41 | <tantek> | I will cc: you on my support forum post. |
| 16:48 | <Ms2ger> | "the new heartbeat requirement from W3C" |
| 16:48 | <Ms2ger> | Is that new? I recall it existing when I still edited in webapps |
| 16:50 | <annevk> | Ms2ger: per http://www.w3.org/2014/Process-20140801/#changes it's not |
| 16:57 | <rubys> | @TabAtkins: ping? |
| 16:57 | <TabAtkins> | rubys: pong |
| 16:58 | <rubys> | Do I need to do anything to enable railroad diagrams? |
| 16:58 | <tantek> | email : wiki :: TR : living-spec |
| 16:58 | <TabAtkins> | rubys: No, you just write them in <pre class=railroad> blocks. |
| 16:58 | <tantek> | email-lists rather |
| 16:58 | <rubys> | What did I do wrong then? http://intertwingly.net/tmp/url.bs produces http://intertwingly.net/tmp/url.html#url-railroad |
| 16:58 | <TabAtkins> | tantek: But I can't respond to a fixed version of the wiki! |
| 16:59 | <tantek> | TabAtkins: But I can't file issues against a living spec! |
| 16:59 | <TabAtkins> | tantek: (that was the joke) |
| 16:59 | <tantek> | TabAtkins: I need more coffee :D |
| 17:01 | <TabAtkins> | rubys: Ah, undocumented requirement that the <pre> be on a line by itself. Sorry about that. |
| 17:01 | <tantek> | TabAtkins: I'm considering putting a WARNING STATIC SNAPSHOT header on all my posts to email lists. |
| 17:01 | <tantek> | which then says to reference the LIVING VERSION HERE (insert wiki URL) |
| 17:02 | <TabAtkins> | (All of the pre-block stuff is done in a preprocessing step before HTML parsing occurs.) |
| 17:02 | <TabAtkins> | rubys: The <pre> tag, that is. Don't put the contents on the same line, obvs. |
| 17:02 | <rubys> | thanks. can we talk about your comments on my conversion here, or would you prefer I respond in github? |
| 17:03 | <TabAtkins> | We can do here, but gimme 20m, as I need to make my wife's lunch. |
| 17:03 | <rubys> | ok |
| 17:04 | <tantek> | TabAtkins: speaking of the <pre> tag, whatever happened to your polyfill for the "separator" attribute on the <pre> tag? http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-1450 |
| 17:05 | <JonathanNeal> | tantek: docs on separator attribute? |
| 17:05 | <tantek> | JonathanNeal: ^^^ click URL |
| 17:05 | <tantek> | it's a way to get CSV functionality into HTML and the DOM |
| 17:06 | <Ms2ger> | It never happened |
| 17:07 | <JonathanNeal> | tantek: i had seen the line you highlighted and looked at http://www.ietf.org/rfc/rfc4180.txt but I didn’t see what it does. I don’t yet get what csv functionality would look like in a pre. |
| 17:08 | <JonathanNeal> | But if I can help, I will! |
| 17:08 | <tantek> | JonathanNeal: <pre separator="\t"> (copy paste a tab-separated CSV text file here) </pre> |
| 17:08 | <tantek> | and if there's a header row then |
| 17:08 | <tantek> | (header row in the CSV) |
| 17:08 | <tantek> | <pre separator="\t" header> (copy paste a tab-separated CSV text file here) </pre> |
| 17:09 | <tantek> | implementation: parse the CSV per that RFC, and add a Table DOM to the pre element accordingly, so it can be styled with CSS table pseudo-elements and accessed by scripts. |
| 17:10 | tantek | waits for dglazkov to show up and say something about perfect opportunity for a Web Component ;) |
| 17:15 | <tantek> | annevk: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html |
| 17:16 | <Domenic> | lolol |
| 17:17 | <tantek> | JonathanNeal: do you use CSV files ever? do you like CSV as a format? |
| 17:18 | <JonathanNeal> | Hardy. Yes. |
| 17:18 | <JonathanNeal> | And it also sounds like the perfect opportuntiy for a web component because it seems like <pre> should never format content. |
| 17:19 | <tantek> | <pre> always formats content |
| 17:19 | <tantek> | (unless you style it explicitly not to) |
| 17:19 | <JonathanNeal> | I thought it tries to display it as raw as possible, which is why I doesn’t ignore whitespace and defaults to monospace? |
| 17:20 | <TabAtkins> | rubys: back |
| 17:20 | <TabAtkins> | tantek: Still exists in the annals of my site. |
| 17:24 | <rubys> | TabAtkins: how do I hand-covert an external link? See also https://github.com/rubys/url/commit/e617fd66135bd75b1052700081de5319914168a5#commitcomment-8262562 |
| 17:24 | <tantek> | TabAtkins: Cool URLs and all that. Nice. |
| 17:25 | <tantek> | JonathanNeal: check out Tab's prototype http://www.xanthir.com/etc/csv.html |
| 17:25 | <annevk> | tantek: heh |
| 17:26 | <tantek> | annevk, glad I can help. |
| 17:26 | <TabAtkins> | rubys: You see if that link exists in Bikeshed's database today (`bikeshed debug --print-refs-for="foo"` isn't great to read, but it has all the necessary data), and if so, you specify what you need to point to it. |
| 17:26 | <TabAtkins> | If the link doesn't exist today, you can add custom anchors with an anchors.json file. |
| 17:27 | <tantek> | I don't always post to email lists, but when I do, I include at least one level of self-referential meta. |
| 17:27 | <TabAtkins> | And let me know, so that I can get Shepherd to start parsing that spec (assuming it has the right metadata for Bikeshed/Shepherd). |
| 17:27 | <TabAtkins> | (And if it doesn't, I can hopefully but the editors to add it.) |
| 17:28 | <JonathanNeal> | tantek: what am I misunderstanding about <pre> that it should format content when it means "preformatted text”? Why not use a new element? |
| 17:28 | <TabAtkins> | csv files are meaningfully readable as preformatted text. They're *more* readable as tables, of course. |
| 17:28 | <tantek> | JonathanNeal: you could use a new element. We used <pre> because <pre> is short for "preformatted text", and CSV/TSV is simply a special case of preformatted text, thus it made sense to re-use. |
| 17:29 | <TabAtkins> | So if you wanted something that worked in the absence of script, <pre> is what you use. |
| 17:29 | <TabAtkins> | Good fallback and all that. |
| 17:29 | <rubys> | TabAtkins, ok, if I substitute 'css' for 'foo', I get some JSON. I take it I should mimic that format and add it to biblio.json (which should be inlined?) |
| 17:29 | <tantek> | Right. 1) Good fallback. 2) minting new elements has greater cognitive cost than adding attributes to an existing element |
| 17:29 | <JonathanNeal> | Well, I’m all for that, and then I would ask that in the future it work with other preformatted types, like JSON, and eventually replace syntax highlighters altogether. |
| 17:29 | <TabAtkins> | anchors.json. Lemme check and see if I'm looking for inline anchors yet, one sec. |
| 17:30 | <tantek> | JonathanNeal: JSON already has <script> tags for embedding it. |
| 17:30 | <TabAtkins> | tantek: That's for *using* json, not displaying it. |
| 17:30 | <JonathanNeal> | Yes, but if I want to display it in a meaningful way, like CSV. |
| 17:30 | <tantek> | whereas <pre> is purely for expectedly *human* readable content |
| 17:31 | <tantek> | TabAtkins: true. JonathanNeal if you want to display some machine-readable code like JSON, we have an element for that. <code> |
| 17:31 | <tantek> | just need a "type" attribute |
| 17:31 | <JonathanNeal> | tantek: agreed on both points, nice |
| 17:35 | <TabAtkins> | rubys: Ah, yeah, I'm not yet recognizing inline <pre class=anchors> data. I'll fix that. For now, external anchors.json file will work. |
| 17:36 | <tantek> | JonathanNeal: <code type="application/json">{ "items": [{ "type": ["h-card"], "properties": { "url": ["http://tantek.com/";], "name": ["Tantek \u00c7elik"]}}]}</code> |
| 17:38 | <Domenic> | rubys: TabAtkins: FWIW I just use <a href="my-blog-post-here">text</a> |
| 17:38 | <TabAtkins> | annevk: I've been thinking of separating out the "default impl" of the FontFace/etc methods from the actual method itself. The intention is that UA-sparked calls use the *initial* value of the property. |
| 17:39 | <TabAtkins> | Domenic: Experience shows that forcing people to do cross-spec links with full href just means, in practice, that people almost never do cross-spec links. |
| 17:39 | <TabAtkins> | As evidence, the CSSWG moved from "very few cross-spec links" to "omg, so many cross-spec links" as specs switched to Bikeshed. |
| 17:39 | <Domenic> | Hmm, I meant more for e.g. the revealing constructor pattern link in https://streams.spec.whatwg.org/#rs-intro |
| 17:39 | <TabAtkins> | Oh, sure, if you want a one-off link. |
| 17:40 | <TabAtkins> | But if you'll be referencing something multiple times in a spec, you want Bikeshed to know about it so you can use short syntax. |
| 17:42 | <rubys> | TabAtkins: ValueError: dictionary update sequence element #0 has length 9; 2 is required |
| 17:42 | <TabAtkins> | ...I have never seen that happen before. |
| 17:43 | <rubys> | At the moment, my anchors.json is exactly the output from bikeshed debug --print-refs-for="css", unmodified |
| 17:43 | <rubys> | last line in the traceback: |
| 17:43 | <rubys> | File "/home/rubys/git/bikeshed/bikeshed/ReferenceManager.py", line 61, in initializeRefs |
| 17:43 | <rubys> | self.refs.update(json.load(fh)) |
| 17:44 | <annevk> | TabAtkins: as an avid reader of standards, I usually understand the intent, but I try to read them in such a way that I don't |
| 17:44 | <TabAtkins> | Ah, kk. That won't work; the output of print-refs-for isn't designed for direct input. Sorry this is kinda messy. |
| 17:45 | <rubys> | TabAtkins: got an example of a working anchors.json anywhere? |
| 17:46 | <TabAtkins> | The top-level needs to be a dict of link text to anchor data, not an array. |
| 17:47 | TabAtkins | is really frustrated that the ChromeOS update he accidentally applied last night killed his crouton, because it means he CAN'T FIX ANYTHING AT ALL RIGHT NOW >_< >_< >_< |
| 17:50 | <rubys> | TabAtkins: does that mean that I don't need the spec= attribute? |
| 17:50 | <TabAtkins> | rubys: Yes, you rarely need to specify the spec; usually just specifying the type and maybe the for is enough. |
| 17:55 | <rubys> | TabAtkins: I'm really longing for a working example. My current error: |
| 17:55 | <rubys> | self.refs[term] = [ref for ref in refs if ref['shortname'].rstrip("\n")!=self.specName] |
| 17:55 | <rubys> | TypeError: string indices must be integers |
| 17:56 | <rubys> | contents of anchors.json (clearly bogus values but should be well-formed): |
| 17:56 | <rubys> | { |
| 17:56 | <rubys> | "utf-8-decoder" : { |
| 17:56 | <rubys> | "status": "TR\n", |
| 17:56 | <rubys> | "export": false, |
| 17:56 | <rubys> | "for": [], |
| 17:56 | <rubys> | "level": "3\n", |
| 17:56 | <rubys> | "url": "http://www.w3.org/TR/css3-conditional/#CSS-interface\n";, |
| 17:56 | <rubys> | "normative": true, |
| 17:56 | <rubys> | "shortname": "css-conditional\n", |
| 17:56 | <rubys> | "type": "dfn\n", |
| 17:56 | <rubys> | "spec": "encoding\n" |
| 17:56 | <rubys> | } |
| 17:57 | <rubys> | ok, that was throttled. Trying again in parts: |
| 17:57 | <rubys> | { |
| 17:57 | <rubys> | "utf-8-decoder" : { |
| 17:57 | <rubys> | "status": "TR\n", |
| 17:57 | <rubys> | ... |
| 17:57 | <rubys> | "type": "dfn\n", |
| 17:57 | <rubys> | "spec": "encoding\n" |
| 17:57 | <rubys> | } |
| 17:57 | <rubys> | } |
| 17:58 | <rubys> | one of the elided lines reads: |
| 17:58 | <rubys> | "shortname": "css-conditional\n", |
| 17:58 | <TabAtkins> | rubys: No one's ever used it, and I am incapable of producing one for you at the moment, as in trying to get my Linux working again. |
| 17:58 | <rubys> | ok, in that case, Dominic's suggestion wins. :-) |
| 17:59 | <TabAtkins> | The real answer is "get all the specs you reference to add the right metadata, then we'll get Shepherd to start parsing then and everyone benefits". |
| 18:00 | <TabAtkins> | Autolinking is an ecosystem thing that doesn't work great for the first few specs in a given clique that try to use it. |
| 18:01 | <TabAtkins> | It's *awesome* for CSS now, since everyone generates thee right metadata. |
| 18:01 | <rubys> | Converting encoding: doable. Converting html and IDNA; https://www.youtube.com/watch?v=zGxwbhkDjZM :-) |
| 18:01 | <TabAtkins> | Yeah... |
| 18:02 | <rubys> | In any case, hard-code hrefs for now; and I'll update to use anchors when you can provide a working example. |
| 18:03 | <TabAtkins> | Kk! |
| 18:07 | <rubys> | TabAtkins: just thinking out loud, why is anchors needed? Shouldn't one or more of the following 'just work'? |
| 18:08 | <rubys> | <a spec=encoding>utf-8</a> or <a spec=dom title=concept-attribute-value>attribute value</a>? |
| 18:08 | <TabAtkins> | Only if Bikeshed knows about those specs, which I don't think it does, currently. |
| 18:08 | <rubys> | but those specs are in my biblio.json |
| 18:08 | <TabAtkins> | Irrelevant - that's a different system entirely. |
| 18:09 | <TabAtkins> | Biblio and autolinking have no connection. |
| 18:09 | <TabAtkins> | (Probably should, but I inherited some legacy biblio systems that are terrible at naming specs.) |
| 18:10 | <rubys> | I'd even settle for <a biblio-spec=encoding>utf-8</a> |
| 18:11 | <TabAtkins> | Still won't help, because if Bikeshed doesn't know the spec, it doesn't know the anchors for that spec. |
| 18:14 | <rubys> | What I meant by that is "create a href by taking the specified spec's href from biblio, and add a hash with the title (computed or provided)" |
| 18:18 | <TabAtkins> | I haven't considered shorter methods for things that arent' in the autolink database yet. I'll think on it. |
| 18:20 | <rubys> | Found the dataloss issue: |
| 18:20 | <rubys> | "<code title>></code>", <!-- 0x3E --> |
| 18:20 | <rubys> | This will fix it: |
| 18:20 | <rubys> | "<code title>></code>", <!-- 0x3E --> |
| 18:21 | <TabAtkins> | That's weird. |
| 18:23 | <TabAtkins> | That really shouldn't be an issue, though. |
| 18:23 | <TabAtkins> | Note that you dont' need an emtpy title there. |
| 18:23 | <TabAtkins> | Bikeshed only treats <a> and <i> as autolinks. |
| 18:24 | <TabAtkins> | (The former only when the element lacks an href attribute, and I'm going to turn off the latter by default.) |
| 18:24 | <TabAtkins> | Holy crap, when you don't update your system for a few months, a full update takes a while. |
| 18:25 | <rubys> | TabAtkins: what OS? |
| 18:25 | <TabAtkins> | And I'm back with a workiong Linux, yay! |
| 18:25 | <TabAtkins> | Ubuntu on Chromebook. |
| 19:04 | <Domenic> | tyoshino________: since you seem to be awake (!?) would love a review of https://github.com/whatwg/streams/pull/234#issuecomment-60016461 |
| 19:57 | <gsnedders> | So, any of you Google people happen to have an Inbox invite to spare? :) |
| 20:01 | <paxcoder> | gsnedders, I don't think you need that anymore. Unless, of course, you think a Google employee's invite might influence the spam filter rating in your favor... |
| 20:02 | <gsnedders> | paxcoder: http://www.google.com/inbox/ |
| 20:02 | <gsnedders> | paxcoder: this isn't Gmail |
| 20:02 | <gsnedders> | paxcoder: so yes, you /can/ request one, but probably quicker to just ask first |
| 20:04 | <paxcoder> | gsnedders, Oh... First time hearing about that. Dat Metr.. umm I mean Material design. |
| 20:05 | <gsnedders> | paxcoder: announced a few hours ago :) |
| 20:07 | <paxcoder> | gsnedders, thanks for the info. |
| 20:07 | <paxcoder> | I like how in the demo/intro, they're not using screenshots or videos. |
| 20:10 | <paxcoder> | gsnedders, I'm also new to templates. How do I know if I should attribute the above to their use? |
| 20:10 | <paxcoder> | (what do I search for in the code?) |
| 20:11 | <gsnedders> | paxcoder: <template>, except this is Google so they probably do something crazy like building it all up through the DOM |
| 20:13 | <paxcoder> | Yeah, the "data-template" attributes seem to agree |
| 21:03 | <Jasper> | Will requestAnimationFrame be called before or after any timeouts in the frame? I couldn't find the ordering of this. |
| 21:03 | <Jasper> | And is there any hook that gets me as close to the "before displaying the finished frame" point in time as possible? |
| 21:07 | <caitp> | i'm not sure how it's spec'd, but from blink's source it looks like the two aren't concerned with each other at all |
| 21:07 | <caitp> | so it's probably implementation-specific |
| 21:08 | <caitp> | or just undefined |
| 21:08 | <Jasper> | Yeah, it's not in the WHATWG HTML spec, only here: http://www.w3.org/TR/animation-timing/ |
| 21:09 | <Jasper> | That's unfortunate. |
| 21:09 | <Jasper> | OK, I think that means I can't actually implement this unless I do (another) shadow copy. OK. I'll just not. |
| 21:17 | <smaug____> | setTimeout and rAF don't really have anything to do with each others |
| 21:19 | <jgraham> | Right, you can never determine the timing of a setTimeout |
| 21:19 | <jgraham> | There isn't any concept of a "same frame" |
| 22:51 | <Hixie> | Jasper: i plan to define it such that the answer is "rAF will be the last callback invoked before the frame is laid out and painted" |
| 22:51 | <Hixie> | Jasper: whether a particular timeout gets done in the current frame or not can't be controlled, it depends on what else is going on |
| 22:51 | <Jasper> | Hixie, right, OK. |
| 22:52 | <Jasper> | jgraham, I thought that the main loop defined the concept of a frame / redraw period |
| 22:52 | <Jasper> | Admittedly, my use case is insane, but I figured I'd ask. |
| 22:56 | <jgraham> | Jasper: No, and setTimeout allows the browser to delay as long as it likes for any reason |
| 23:00 | <Hixie> | yeah, setTimeout just queues a task, there's no guarantee of when it'll be serviced |
| 23:00 | <Hixie> | right now the event loop is veeeery vague about frames. that'll hopefully improve a little when i get to that bug. |
| 23:05 | <Hixie> | what's the difference between a prototype and a constructor again? I thought I knew, but then I read the spec for GetSuperConstructor() and it seems to say that they're the same. |
| 23:07 | <TabAtkins> | Hixie: An object's prototype is just another object, which is used for lookup when you ask for a property and it doesn't exist on the object. |
| 23:07 | <TabAtkins> | A constructor is a function. |
| 23:07 | <TabAtkins> | Typically, an object's proto is set to the value of the "prototype" property on the constructor function at the time the object is constructed. |
| 23:12 | <Hixie> | and foo.prototype is not foo's prototype, right? it's just the prototype that'll be used if you new up an object using new as a constructor? |
| 23:12 | <Hixie> | but __proto__ is the prototype? is there an official way of getting to __proto__? |
| 23:14 | <TabAtkins> | Hixie: Right, or rather, it's not necessarily. ^_^ __proto__ is the prototype, and that's the official way to get it. |
| 23:14 | <TabAtkins> | There's also getPrototypeOf(), I think. |
| 23:14 | <Hixie> | __proto__ seems to be shunned in the spec |
| 23:14 | <Hixie> | though i guess it is there, at least |
| 23:15 | <TabAtkins> | Using it de-optimizes your object, so you don't want to use it normally. |
| 23:18 | <Hixie> | so why doesn't this work: |
| 23:18 | <Hixie> | foo = { bar: 3 } |
| 23:18 | <Hixie> | Object.setPrototypeOf(foo, Object.getPrototypeOf(Object.getPrototypeOf(document.body))); |
| 23:18 | <Hixie> | Object.setPrototypeOf(Object.getPrototypeOf(document.body), foo); |
| 23:18 | <Hixie> | document.head.bar |
| 23:18 | <Hixie> | or maybe i should ask, should that work? |
| 23:18 | <gsnedders> | you probably can't mutate the prototype of host objects |
| 23:19 | <gsnedders> | or whatever they're called now |
| 23:19 | <gsnedders> | whether that's a good idea or not is a separate question :) |
| 23:29 | <Hixie> | is there a way to test if super() is going to throw because the function isn't defined? |
| 23:31 | <Hixie> | oh wait, super only works inside functions defined in class blocks, right |