/irc-logs / freenode / #whatwg / 2014-04-25 / end

Options:

# Session Start: Fri Apr 25 00:00:00 2014
# Session Ident: #whatwg
# [00:00] * Quits: Ms2ger (~Ms2ger@91.180.172.211) (Quit: nn)
# [00:00] * Quits: cheron (~cheron@unaffiliated/cheron) (Quit: Leaving.)
# [00:00] <zewt> that's the web compatibility question, or part of it: does anyone use anchors with "##" in them
# [00:00] * SamB already reported https://bugzilla.mozilla.org/show_bug.cgi?id=978431 about http://simonstl.com/articles/cssFragID.html ... could would happily close that as a dupe of something like what zewt is talking about
# [00:01] <KevinMarks_> OK, ignore the ##
# [00:01] <zewt> then what am I supposed to be answering :)
# [00:02] <KevinMarks_> imagine this bit of the spec http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document
# [00:02] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [00:03] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [00:03] <KevinMarks_> has before item 8, "if fragid is a whitespace-insenstitve match for innertext within the document, the indicated part of the document is the containing element of that innertext"
# [00:04] * Quits: zdobersek (~zan@179.43.133.194) (Quit: Leaving.)
# [00:04] <KevinMarks_> er, s/decoded fragid/fragid
# [00:05] <KevinMarks_> this doesn't stop any other use of fragments, it just adds some more cases where target is valid and potentially scrolls the document
# [00:06] <zewt> it makes a total mess of other use of fragments, as I said
# [00:06] <KevinMarks_> no it doesn't
# [00:06] <KevinMarks_> only in the same way as IDs do
# [00:06] <SamB> yeah, basically
# [00:06] <zewt> no, far more, as I explained already
# [00:06] <SamB> assuming by IDs you also mean NAMEs
# [00:06] <KevinMarks_> IDs and NAMEs yes
# [00:07] <KevinMarks_> things above 8 in the bit of spec text
# [00:07] <SamB> of course, that was the first use
# [00:07] <KevinMarks_> "top" too
# [00:07] <zewt> if css selectors were added, http://foo.com##table could mean "scroll to the first instance of the word table", or "scroll to the first <table>" element
# [00:07] <zewt> which is a total mess
# [00:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
# [00:07] <zewt> the solution is simple and low-cost: http://foo.com##text=table
# [00:07] <KevinMarks_> it also would mean "Scroll to element with id="#table" like it is now
# [00:07] <SamB> you can sort of understand them not thinking ahead so well at the beginning
# [00:08] <KevinMarks_> scroll to Scroll to element with id="#text=table"
# [00:08] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [00:08] <zewt> new browsers supporting this would never tried to scroll to "#table", obviously
# [00:08] * Joins: hasather (~hasather@guest.schibsted.no)
# [00:08] <KevinMarks_> everything you say about this is true of ID already
# [00:08] <SamB> but now that we've already got lots of ideas about what fragments ought to be able to do, *and* conflicts between existing uses ...
# [00:08] <zewt> and this is even more specific--the changes of there being a link to an id "#text=table" is smaller
# [00:09] <zewt> so it both reduces the chance of web compat issues, and allows future features much more easily
# [00:09] <zewt> if the only counterargument is "man, I don't want to have to type #text= once in a while", well... :)
# [00:10] <KevinMarks_> you are making categorical statements about this proposal that are untrue
# [00:11] <zewt> your arguments seem to be of the form "no it's not" and "that's untrue", which nobody can do much with
# [00:11] <KevinMarks_> clearly we do need that survey of existing IDs adn fragments on the web to settle the probablistic arguments
# [00:11] <zewt> anyway, time to go home
# [00:12] <zewt> back in a bit
# [00:12] <KevinMarks_> no, my argument is that IDs already consume the namespace
# [00:12] <SamB> KevinMarks_: longer things are less likely to occur than substrings of them
# [00:12] <KevinMarks_> except fro spaces
# [00:12] <Hixie> SamB: agreed... what do you suggest instead, though? i'm scraping the bottom of the barrel for ideas here :-(
# [00:12] <KevinMarks_> so requiring spaces doesn't collide with IDs
# [00:13] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 252 seconds)
# [00:13] <SamB> is that so?
# [00:13] <KevinMarks_> http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation
# [00:14] <KevinMarks_> decodes the fragid "remote+annotation" to "remote annotation" which cannot match an ID
# [00:14] <KevinMarks_> (that link works BTW)
# [00:14] <KevinMarks_> so the weak fragmentions argument requires a space
# [00:15] <KevinMarks_> the strong fragmentions argument says any text that isn't an ID in the document is fair game as a fragmention
# [00:15] <KevinMarks_> eg http://sandbox.thewikies.com/fragmentions/example.html#of
# [00:16] <KevinMarks_> which may be overbroad
# [00:16] <KevinMarks_> but still doesn't harm IDs
# [00:16] <SamB> and what is so special about fragmentions that makes you think *it* should be so enshrined in the html spec?
# [00:16] <JonathanNeal> what about the argument of using uncharted, presently invalid space, like ##?
# [00:17] <JonathanNeal> SamB: same reason hash anchors are represented, access to content.
# [00:17] <KevinMarks_> zewt says he wants that for all kinds of magic jquery style CSS stuff in some hypotherical future
# [00:17] <KevinMarks_> SamB there is a huge use case for referring to text remotely
# [00:18] <KevinMarks_> *text* not structure
# [00:19] <KevinMarks_> effectively every reference to another work can be represented as a quotation from it
# [00:19] <KevinMarks_> google is the existence proof
# [00:19] <KevinMarks_> https://www.google.com/search?q=%22If+you+get+the+right+ones+in+the+right+order%22
# [00:20] <KevinMarks_> is a better anchor for the play text I'm referring to than a URL
# [00:21] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [00:22] <KevinMarks_> heh, and my fragmentions page is now #4 for it on google
# [00:22] <KevinMarks_> ten words is enough to identify that quote globally
# [00:23] <KevinMarks_> 4 is probably enough for a given document
# [00:23] <KevinMarks_> except for villanelles
# [00:24] <SamB> that doesn't give your idea a divine right to this syntax ...
# [00:24] <KevinMarks_> http://www.kevinmarks.com/poemfragmentions.html##Do+not+go+gentle+into+that+good+night.+Rage,+rage+against+the+dying+of+the+light.
# [00:24] <KevinMarks_> not arguing that
# [00:24] <KevinMarks_> standards are documentation, not legislation
# [00:25] <KevinMarks_> I contend that this is useful, we're shipping it on the web in various places
# [00:25] <TabAtkins> KevinMarks_: "all kinds of magic jquery style CSS stuff" is a misstatement. The idea of using selectors in the frag to find an element has a long history.
# [00:27] <KevinMarks_> TabAtkins: got some spec text or proposals I can link to from http://indiewebcamp.com/fragmention#Related_work?
# [00:27] <TabAtkins> http://simonstl.com/articles/cssFragID.html
# [00:27] * TabAtkins http://www.w3.org/community/cssselfrags/
# [00:27] * TabAtkins https://bugs.webkit.org/show_bug.cgi?id=100841
# [00:27] <KevinMarks_> thanks!
# [00:28] <TabAtkins> I literally just googled for "selectors in fragment"
# [00:28] <TabAtkins> There are a bunch more.
# [00:28] <KevinMarks_> yes, lots of prior art
# [00:28] <KevinMarks_> all of which are complicated as heck
# [00:29] <KevinMarks_> and thus wouldn't collide
# [00:29] <KevinMarks_> :D
# [00:30] <TabAtkins> What do you mean by "complicated as heck"?
# [00:30] <TabAtkins> Simon St Laurent's last proposal is "example.com#css(.foo)"
# [00:30] <KevinMarks_> I mean #css(div[class~="content"]:nth-child(2))
# [00:30] <TabAtkins> It's exactly as complicated as your selector is.
# [00:31] <zewt> the thing samb and I explained it extraordinarily simple
# [00:31] <KevinMarks_> is not in namespace contention with #more+complicatd
# [00:31] <SamB> KevinMarks_: yes, it is
# [00:31] <zewt> is not a parsable sentence
# [00:32] <KevinMarks_> or rather it is already in contention with IDs
# [00:32] <zewt> please restate your argument against "##text=foo", because I don't understand it
# [00:32] <SamB> well, okay, not insofar as it has no parens in it, but ...
# [00:32] <zewt> "##" is a hack to work around the unextensibility of the hash; if that works (isn't blocked by web compat), we should do it in a way that only has to be done once and can be reused
# [00:33] <zewt> (the single-# thing I'm pretty certain is a non-starter for web compat reasons)
# [00:33] <KevinMarks_> can we separate these two
# [00:34] <KevinMarks_> I am interested int the web compat reasons
# [00:34] <KevinMarks_> because that is the heart of this
# [00:34] <KevinMarks_> can you explain how this breaks web compatibility
# [00:34] <SamB> the web compat reasons are that it's going to be a pain to find and verify ONE piece of syntax to steal
# [00:35] <KevinMarks_> can you rephrase that in less lodded terms please
# [00:36] <KevinMarks_> you are saying this will collide with something?
# [00:36] <zewt> if you have a link http://foo.com, and there's an ID "credits", what does http://foo.com#credits mean?
# [00:36] <KevinMarks_> it means go to ID credits
# [00:36] <zewt> you either have a web compat issue (it breaks links to the credits), or you're unable to do a text link to the string "credits"; both are bad
# [00:36] <KevinMarks_> IDs win over text
# [00:36] <SamB> (or, well, maybe I was going in the wrong direction ...)
# [00:36] <KevinMarks_> what does http://foo.com#credits+ mean?
# [00:36] <zewt> so you want a text-search-link feature that doesn't work if the page happens to have an ID with the word the user wants to link to?
# [00:36] <KevinMarks_> it no longer matches that ID
# [00:37] <zewt> what? that's gross
# [00:37] <SamB> indeed, very gross
# [00:37] <zewt> hope that's not a serious suggestion heh
# [00:37] <KevinMarks_> absolutely
# [00:37] <zewt> ...
# [00:37] <KevinMarks_> it's what I have working
# [00:37] <zewt> sorry, too insane for me to even know how to reply
# [00:37] <KevinMarks_> this is how I know i'm safe
# [00:37] <SamB> it doesn't really matter all that much what you have working
# [00:38] <KevinMarks_> you all think this is insane, because you haven't seen it on the web
# [00:38] <KevinMarks_> hence no collisions
# [00:38] <zewt> no, we think it's insane because it's an ugly, nasty hack (even uglier than ##, and far less functional)
# [00:38] <SamB> you have to sell it to the browser vendors ...
# [00:38] <KevinMarks_> I'm hearing emotion words, not arguments
# [00:39] <KevinMarks_> "ugly, nasty" is cognitive dissonance
# [00:39] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [00:39] <zewt> we've already responded to everything you've said, and you've given little to no useful response
# [00:39] <KevinMarks_> you haven't responded
# [00:39] <zewt> ...
# [00:39] <zewt> okay, i'm done for now :)
# [00:39] <TabAtkins> Note that Media Fragments claims a relatively safe portion of the fragment syntax space just by assuming that "foo=..." is safe to claim.
# [00:39] <KevinMarks_> I say that fragments with spaces in don't collide with IDs
# [00:40] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [00:40] <TabAtkins> video.mp4#t=5s, for example.
# [00:40] <SamB> TabAtkins: I heard they specifically excluded HTML though?
# [00:40] <TabAtkins> We should probably make sure that everybody claims fragment syntax in the same way.
# [00:40] <KevinMarks_> media fragments explicitly exclude htmls
# [00:40] <zewt> TabAtkins: my suggestion is http://foo.com#ignored##key=value, because that can coexist with many client-side uses of the hash
# [00:40] <TabAtkins> SamB: Not too relevant. SVG does the same thing.
# [00:41] <KevinMarks_> this can coexist with client-side uses of the hash
# [00:41] <zewt> (samb's originally, I think)
# [00:41] <SamB> KevinMarks_: in the same link?
# [00:41] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
# [00:41] <KevinMarks_> what?
# [00:42] <KevinMarks_> where did "in the same link" come from?
# [00:42] <TabAtkins> Actually, SVG uses "#foo()" form.
# [00:42] <SamB> zewt: well, you came up with the key=value idea; my thinking was just that there should be some sort of a name to indicate which new thing ...
# [00:42] <TabAtkins> zewt: Yeah, I prefer using = over function syntax.
# [00:42] <SamB> KevinMarks_: see the example above?
# [00:42] <KevinMarks_> I do, yes what does it represent
# [00:43] <zewt> fwiw, i think it could be defined simply as "the string #text= followed by characters other than #", with no higher-level "parse out key/values" algorithm
# [00:43] <zewt> ##text
# [00:44] <SamB> KevinMarks_: difficult to say; it's rather meta
# [00:44] <TabAtkins> I think it's fine to claim #text=
# [00:44] <zewt> TabAtkins: i think that's extremely bad
# [00:44] <TabAtkins> Why? Pretty sure it'd be safe to claw that out of the ID space.
# [00:45] <zewt> it's the space for scripts to stash stuff in the hash that I'm more concerned about
# [00:45] <KevinMarks_> you're all fighting for the ID space. Mine doesn't collie with it at all
# [00:46] <KevinMarks_> and scripts stuffing things in the hash aren't going to collide except in documents discussing those scripts
# [00:46] <KevinMarks_> and only if they use spaces
# [00:46] <TabAtkins> KevinMarks_: Orthogonal concerns. Even if we decided to use a different syntax like ##foo, we'd still want to make sure it's possible to use more functions than just "match text".
# [00:47] <KevinMarks_> TabAtkins: how does this stop that?
# [00:47] <KevinMarks_> it's possible to use more functions than just "match ID" now
# [00:47] <TabAtkins> Everyone's been over that. Making "##foo" be the "search for 'foo' text" syntax claims the entire syntax space.
# [00:47] <Hixie> what's the problem y'all are trying to solve? (sorry, not been paying attention so far)
# [00:47] <SamB> as you can see, there are a lot of people who want various pieces of this action; it's best if we can come up with something that avoids people having to worry about stepping on eachothers toes in the process ...
# [00:48] <KevinMarks_> ID already claims the entire syntax space
# [00:48] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Ping timeout: 264 seconds)
# [00:48] <SamB> KevinMarks_: yes, well, if we're going to steal some we need to do it properly
# [00:48] <TabAtkins> Hixie: Trying to solve the problem of multiple specs wanting to put things in the fragment space.
# [00:48] <KevinMarks_> if you manage without colliding with IDs, you'll manage with this
# [00:48] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 264 seconds)
# [00:48] <KevinMarks_> Hixie: the fragmentions idea
# [00:49] <zewt> "we already have a collision with IDs" != "we should stuff whatever unstructured stuff we want in the hash and not care about making things worse"
# [00:49] <Hixie> TabAtkins: ah, a time-honoured problem for people to try to solve :-)
# [00:49] <TabAtkins> KevinMarks_: There's a difference between "No real IDs use an = character" and "No one will ever want to search for an = character"
# [00:49] <Hixie> KevinMarks_: fragmentations idea?
# [00:49] <SamB> Hixie: no, fragmentions
# [00:49] <Hixie> (in practice, the fragid space in HTML docs is page-defined, and entirely under the control of the page)
# [00:49] <TabAtkins> Frag-mentions.
# [00:49] <SamB> it's a portmanteu (however that's spelt)
# [00:49] <Hixie> frag-mentions?
# [00:50] <zewt> Hixie: http://foo.com##text=hello linking to the first text match of "hello" (using one of the syntaxes we've discussed)
# [00:50] <Hixie> oh, linking to a text match
# [00:50] <Hixie> interesting
# [00:50] <KevinMarks_> http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation
# [00:50] <zewt> (obviously, the web compat and hash namespace issues are biggies)
# [00:50] <TabAtkins> (Probably actually pre-filling the browser's Ctrl+F UI.)
# [00:50] <SamB> http://indiewebcamp.com/fragmention links to several related things ...
# [00:50] <Hixie> yeah you don't want to do that using fragids, pages can already use that space for whatever purpose they want
# [00:50] <KevinMarks_> a single word is a problem
# [00:50] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [00:50] <KevinMarks_> multiple words isn't
# [00:50] <TabAtkins> Hixie: So the idea so far is to lean on ## as the introducer syntax.
# [00:50] <KevinMarks_> hang on
# [00:51] <KevinMarks_> I'm backing off ##
# [00:51] <zewt> we're not :)
# [00:51] <KevinMarks_> and being more ambitious
# [00:51] <KevinMarks_> IDs cannot contain spaces
# [00:51] <KevinMarks_> so http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation
# [00:51] <KevinMarks_> means what now?
# [00:51] <SamB> KevinMarks_: it might be possible to use that space but it would be more annoying to would-be linkmakers
# [00:51] <Hixie> KevinMarks_: fragment identifiers aren't limited to IDs
# [00:51] <TabAtkins> Your idea means I can't search for a single word.
# [00:51] <Hixie> and "+" in fragment identifiers means "+", not " "
# [00:51] <zewt> TabAtkins: he wants you to put a dummy space at the end
# [00:52] <TabAtkins> Oh, bleh.
# [00:52] <KevinMarks_> not in every browser I've tried it
# [00:52] <zewt> my reaction too
# [00:52] <TabAtkins> That doesn't work either.
# [00:52] <SamB> dummy space isn't even actually possible
# [00:52] <TabAtkins> I might be searching for a word prefix.
# [00:52] <SamB> browser removes it
# [00:52] <TabAtkins> I do that in the Ctrl+F UI regularly.
# [00:52] <SamB> I don't know if fragmentions can even search for word fragments
# [00:52] <astearns> the part of the URL that contains the fragmention is the fragmention container, so it will have to be called the fragmentiontainer
# [00:52] <SamB> astearns: lol
# [00:52] <SamB> you win
# [00:52] <zewt> anyway, ## solves (or attempts to solve) a number of problems, including possibly improving the situation we have today where you can't use both #anchors and script-data-stored-in-the-hash at the same time
# [00:52] <KevinMarks_> Hixie, click that lint
# [00:52] <KevinMarks_> *link
# [00:53] <SamB> zewt: ## is at least a good stand-in for a solution
# [00:53] <KevinMarks_> I don't actually care about the single word case
# [00:53] <zewt> SamB: making http://foo.com#clientdata##id=foo behave like http://foo.com#foo does today seems to solve it pretty well
# [00:53] <Hixie> KevinMarks_: what about it?
# [00:54] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:54] <KevinMarks_> because my use case is robust anchors to text content
# [00:54] <astearns> KevinMarks_: the single word case seems like a huge use case to me - I'm annotating this word to mention that it's mispelled
# [00:54] <KevinMarks_> so multiword is better
# [00:54] <zewt> SamB: it doesn't fix it automatically (the site may need to adjust parsing to handle it, or know how to preserve the ##extra stuff in the URL), but it gives them a *way* to do it, which today doesn't exist at all
# [00:54] <KevinMarks_> astearns: in practice you give search phrase
# [00:54] <SamB> can I point out that I think I'm extremely likely to want to link to something other than the first occurance?
# [00:55] <KevinMarks_> which is why you use more words
# [00:55] <Hixie> fragment identifiers are a reserved space for use by the page, you can't add UA logic there beyond what's there already
# [00:55] <zewt> SamB: i'm inclined to punt that as a use case for a possible future "css selectors in the url" proposal
# [00:55] <SamB> zewt: I was sort of assuming we'd want to roll out browsers segregating that stuff from .fragment as the first step
# [00:55] <JonathanNeal> KevinMarks_: for the sake of argument, if ## is used, what are the next concerns? < Hixie, TabAtkins
# [00:55] <KevinMarks_> http://www.kevinmarks.com/poemfragmentions.html##occurs+more
# [00:55] <Hixie> otherwise you'd break e.g. fragmention.js
# [00:56] * Joins: jwalden (~waldo@corp-nat.p2p.sfo1.mozilla.com)
# [00:56] <KevinMarks_> I'm not adding more UA logic
# [00:56] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [00:56] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:7993:aff7:6535:bb5c)
# [00:56] <Hixie> oh
# [00:56] <KevinMarks_> I'm just expanding the ability to express "the indicated part of the document"
# [00:56] * Joins: rniwa (~rniwa@17.202.43.222)
# [00:56] <TabAtkins> ...which is UA logic.
# [00:56] <Hixie> o_O
# [00:56] <Hixie> i'm confused
# [00:57] <zewt> Hixie: the web compat problem is important, but it's not obvious to me that having (eg.) "##id=foo" jump to <div id=foo> isn't web-compatible enough
# [00:57] <Hixie> do you want UAs to change behaviour or not?
# [00:57] <SamB> Hixie: well, presumably we could key off of "#" "#" ID "=" ?
# [00:57] <TabAtkins> UA logic being "anything the UA does for you", as opposed to "something that in-page scripts do".
# [00:57] <Hixie> there are pages that take the fragid and do stuff with it
# [00:57] <Hixie> stuff like "draw it on a canvas"
# [00:57] <zewt> i've written many of them myself :)
# [00:57] <Hixie> or "send an e-mail"
# [00:57] * Joins: othermaciej (~mjs@17.114.219.154)
# [00:57] <Hixie> or whatever
# [00:57] <SamB> Hixie: I want the URL parsing to change, and hide this from old pages
# [00:57] <KevinMarks_> I want UAs to change behaviour. I am arguing that this does not in any way affect the other uses of fragments by client code
# [00:57] <Hixie> oh well if you want to change URL parsing, that's a different matter
# [00:57] <KevinMarks_> and this would not affect them
# [00:58] <zewt> SamB: i just thought about that a little, but changing that is scary...
# [00:58] * Hixie will leave fighting changing the url parsing spec to anne
# [00:58] <KevinMarks_> I want to add a step between 7. and 8. here http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document
# [00:58] <Hixie> KevinMarks_: yeah, you can't do that
# [00:58] <Hixie> KevinMarks_: that breaks pages that use the fragment identifier
# [00:58] <SamB> zewt: well, it seems impractical to expect every JS app that uses fragments to change
# [00:58] <zewt> SamB: for example, if saying document.location.protocol + document.location.hostname ..... + document.location.hash no longer reconstructs the URL
# [00:58] <KevinMarks_> how?
# [00:58] <SamB> which seems like the alternative?
# [00:58] <Hixie> KevinMarks_: you could do it the way SamB suggests
# [00:58] <Hixie> KevinMarks_: and change the url parser
# [00:59] <SamB> zewt: hmm
# [00:59] <zewt> SamB: (because part of the hash is no longer inside .hash)
# [00:59] <KevinMarks_> hear me out, Hixie
# [00:59] <SamB> I'm not sure if I'd want to change .hash
# [00:59] <Hixie> KevinMarks_: suppose a page takes the fragid and draws it on a canvas
# [00:59] <KevinMarks_> OK
# [00:59] <Hixie> KevinMarks_: you've just made that page have wacked behaviour for certain fragIDs
# [00:59] <SamB> Hixie: assuming it has words on it
# [00:59] <KevinMarks_> no more than if there is an ID in the page that matches it
# [00:59] <Hixie> SamB: right
# [01:00] <zewt> Hixie: it seems okay if the new feature doesn't work on 100% of pages, as long as it doesn't break existing pages/links (or whatever small percent of breakage vendors are OK with)
# [01:00] <Hixie> KevinMarks_: right, but they already know about that
# [01:00] <SamB> KevinMarks_: but it would KNOW about the IDs
# [01:00] <Hixie> KevinMarks_: so they already have to deal with it
# [01:00] <Hixie> zewt: there's 100s of trillions of pages. unless the number is 0, the number is probably too high.
# [01:00] <SamB> the best case here is if we can make this work even for pages that already use their fragments in script
# [01:00] <zewt> trying to contrive actual web breakage: a site might use a weird not-base64 binary encoding in their hash, which could end up encoding some binary blob to a string including "##text=hello"
# [01:01] * Quits: lokling (~quassel@quassel.woboq.de) (Read error: Operation timed out)
# [01:01] <zewt> s/actual/potential/
# [01:01] <SamB> we at least need to avoid actually BREAKING such pages
# [01:01] * Joins: benvie_ (~bbenvie@corp-nat.p2p.sfo1.mozilla.com)
# [01:01] * Joins: ap_ (~ap@17.114.217.152)
# [01:01] <zewt> that page would break if .hash changed, but it might not if .hash stays the same (which I'm pretty sure it should) and it just causes the browser to try to scroll to "hello"
# [01:01] * Joins: lmcliste_ (~lmclister@192.150.10.210)
# [01:02] <KevinMarks_> so we're back to what I said originally - is there a good survey of existing IDs and fragment URLs in the wild?
# [01:02] * Joins: lokling (~quassel@quassel.woboq.de)
# [01:02] <KevinMarks_> like Hixie did for classes?
# [01:02] * Quits: payman (~payman@ip-200.t2.se.opera.com) (Read error: Operation timed out)
# [01:02] <SamB> hmm, what do typical .hash-using pages in the wild actually DO with their .hash strings?
# [01:02] * Joins: payman (~payman@ip-200.t2.se.opera.com)
# [01:02] <Hixie> KevinMarks_: such a survey wouldn't help, what you need is an inspection-based examination of pages that use location.hash
# [01:02] <KevinMarks_> 'cos that's how you settle "you might break this carefully constructed edge case" argument
# [01:02] <zewt> SamB: probably everything conceivable :P
# [01:02] <JonathanNeal> I’d still like to know from Hixie or TabAtkins what happens if we just use the ## space, as those are presently invalid, and let browsers honor the invalid ##term as they already would when <div id="#term">.
# [01:02] * Quits: bentruyman (~bentruyma@23.252.119.254) (Read error: Operation timed out)
# [01:02] * Quits: benvie (~bbenvie@corp-nat.p2p.sfo1.mozilla.com) (Read error: Operation timed out)
# [01:02] <Hixie> JonathanNeal: nothing is invalid in a fragid
# [01:02] * Joins: bentruyman (~bentruyma@23.252.119.254)
# [01:03] <zewt> invalid as an @id link doesn't mean you can't put it in the fragment at all
# [01:03] <SamB> unfortunate truth :-(
# [01:03] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:7993:aff7:6535:bb5c)
# [01:03] <JonathanNeal> Hixie, ah, cool, and what are your thoughts on reserving some of that space for targeting elements by text?
# [01:03] <SamB> the "nothing is invalid" bit, I mean
# [01:03] <zewt> i think he just gave his thoughts :P
# [01:03] <SamB> JonathanNeal: no that's not cool :-(
# [01:03] * Quits: lmclister (~lmclister@192.150.10.210) (Ping timeout: 252 seconds)
# [01:04] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [01:04] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net) (Remote host closed the connection)
# [01:04] <KevinMarks_> A fragment must be zero or more URL units. http://url.spec.whatwg.org/#url-code-points does not include #
# [01:04] <JonathanNeal> SamB: so I’m clean, you are saying that anything using a hash to search for text on a page, regardless of the syntax, is not cool?
# [01:04] * Quits: ap_ (~ap@17.114.217.152) (Client Quit)
# [01:04] <SamB> Hixie: oh did you see the link to http://simonstl.com/articles/cssFragID.html yet?
# [01:04] * Quits: ap (~ap@2620:149:4:304:9507:41f9:9151:1e7e) (Ping timeout: 240 seconds)
# [01:05] <KevinMarks_> so #%23foo is needed to produce a decoded fragid of "#foo"
# [01:05] * Quits: othermaciej (~mjs@17.114.219.154) (Quit: othermaciej)
# [01:05] <Hixie> JonathanNeal: retroactively reserving space is usually a lost cause
# [01:05] * Quits: encryptd_fractal (~encryptd_@96-42-47-51.dhcp.ftbg.wi.charter.com) (Ping timeout: 255 seconds)
# [01:06] * Joins: jernoble|laptop (~jernoble@17.202.45.163)
# [01:06] <Hixie> KevinMarks_: maybe in theory, but not in practice
# [01:06] <SamB> Hixie: obviously based on our discussion we're not sure that's a good plan for the actual syntax, but the things it allows one to *represent* seem useful ...
# [01:06] <KevinMarks_> which is what we found
# [01:06] * Joins: othermaciej (~mjs@17.114.219.154)
# [01:06] <KevinMarks_> though some UA's converted ## into #%23 notably colloquy
# [01:06] <SamB> KevinMarks_: you may have found a bug in the URL spec
# [01:06] <Hixie> SamB: yeah, xpointer is one of the big over-engineered ways to solve this problem. and it doesn't solve it. :-)
# [01:07] <Hixie> (and it went nowhere)
# [01:07] <zewt> as a terrible logical-extreme case, do you think "##0271a91a-86a0-4773-b042-eb535834e0d8=hello" would be web-incompatible?
# [01:07] <SamB> Hixie: it would help if we had a way to actually *use* it
# [01:07] <SamB> I mean in a link
# [01:07] <Hixie> anyway i don't want to be the stop energy in the room here, i mean, if you guys can figure out a way to do it, go for it :-)
# [01:07] <KevinMarks_> there are variations of complex queries going back to 1998 that didn't work
# [01:07] <Hixie> zewt: it would break the script i mentioned earlier, yes
# [01:08] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Remote host closed the connection)
# [01:08] <KevinMarks_> the simple one goes right through the gap
# [01:08] <Hixie> zewt: (unless we change url parsing to hide it from .hash)
# [01:08] <SamB> hmm, my next crazy idea is to invent a new Unicode character especially to start one of these babies
# [01:08] <SamB> that probably doesn't actually work though
# [01:08] <Hixie> zewt: (though then we break the scripts that concatenate, as you mentioned)
# [01:08] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [01:08] <SamB> hmm, FWIW, I think it's acceptable if a script tries to reconstruct its URL and loses the extras
# [01:09] <zewt> Hixie: sorry, which script? (what I'm looking for is how it could have web compatibility issues, given that no link on the web contains that text)
# [01:09] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [01:09] <KevinMarks_> http://zesty.ca/crit/draft-yee-url-textsearch-00.txt
# [01:09] * Joins: hasather (~hasather@guest.schibsted.no)
# [01:09] * Quits: zama (zama@2604:180::502b:135a) (Remote host closed the connection)
# [01:09] <SamB> I don't think the IETF is in charge of URLs anymore, KevinMarks_
# [01:09] <zewt> (I'm willing to make the leap of faith that no URL on the web contains a UUID that I just generated)
# [01:10] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
# [01:10] <zewt> i guess we might be talking about different parts of web-compatible, too
# [01:10] <SamB> zewt: oh, the one with the canvas that draws its fragment identifier
# [01:11] <zewt> SamB: but no links actual exist with that string in it
# [01:11] <KevinMarks_> got a link for drawing fragids on canvas
# [01:11] <KevinMarks_> ?
# [01:11] <KevinMarks_> I can see if the chrome plugin breaks it
# [01:11] <zewt> you might create a link in the future that wouldn't work, but there's a big difference between breaking links that someone creates after the feature is deployed (they try it and simply notice it didn't work) and breaking ones that already exist (that's what I think of for "web compat")
# [01:12] <KevinMarks_> agreed
# [01:12] <KevinMarks_> I don't think this breaks links
# [01:12] <KevinMarks_> thats where we keep going in circles
# [01:12] <SamB> Hixie: anyway, personally I either won't want to link to words on that page in the first place, or can live with the silly things it decides to draw on its canvas when I do ...
# [01:12] <Hixie> zewt: http://damowmow.com/playground/demos/fragment-identifiers/002.html##0271a91a-86a0-4773-b042-eb535834e0d8=hello
# [01:12] <KevinMarks_> samB quite
# [01:13] <zewt> Hixie: but that's not breaking links that exist today (putting aside web IRC logs of this discussion), since nobody's creating links using that feature (since it doesn't exist yet)
# [01:13] <Hixie> zewt: it means you can't use that feature on that page
# [01:13] <zewt> right
# [01:13] <zewt> that seems different than "web compatibility" as I understand it
# [01:13] <SamB> Hixie: yeah, true, which is bad :-(
# [01:13] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
# [01:13] <zewt> the feature doesn't work with the page, but the page itself isn't broken
# [01:13] <Hixie> zewt: that seems pretty lame if we can't come up with a feature that works on all pages
# [01:14] <SamB> but "can't use it on that page" > "can't use that page because of it", obviously
# [01:14] <zewt> the web can be pretty lame (you know that better than me :), but "we can't do this feature perfectly" is usually not a good reason to not do it at all
# [01:14] <Hixie> well it means that if you actually WANT to display "#0271a91a-86a0-4773-b042-eb535834e0d8=hello", you can't do it, because it would jump to the word "hello"
# [01:14] <SamB> Hixie: yeah, that was why I said we should try to allow this along with a fragment ID, and preferably along with other ## .. = stuff
# [01:14] <KevinMarks_> it would jump to it and display it
# [01:15] <zewt> right
# [01:15] <SamB> Hixie: yeah
# [01:15] <Hixie> SamB: yeah, changing the url parsing to add a new component to urls seems like a prereq to making anything like this work, imho. but i don't know how plausible even that would actually be.
# [01:15] <zewt> messing with location.hash is scary as hell, heh
# [01:15] <SamB> Hixie: yeah, exactly my thinking ...
# [01:15] <KevinMarks_> I'm all Eppur Si Muove on this working
# [01:16] <SamB> I'm not really sure if it should be included or excluded from location.hash
# [01:16] <zewt> SamB: that sounds like the implication from what hixie said, though
# [01:16] <Hixie> if we change the url parsing, it should be excluded
# [01:16] <Hixie> otherwise you haven't changed url parsing
# [01:16] <zewt> it'd have to not be in location.hash if you want that canvas page to "just work"
# [01:16] <KevinMarks_> empirically, being able to link by text content is really handy
# [01:16] <Hixie> i updated the spec header again, btw. made it way tighter.
# [01:16] <Hixie> and added a gradient
# [01:17] <Hixie> can't wait to see the reaction of all the other whatwg spec editors when they wake up and find their specs have changed!
# [01:17] <SamB> what API would be appropriate for accessing that portion of the URL for at least those things that the browser doesn't grok yet?
# [01:17] <Hixie> KevinMarks_: i dunno, i think it's a bit of an esoteric feature in practice
# [01:17] <zewt> (i don't know if any pages parse out document.location.href and ignore .hash, anything doing that is probably a lost cause)
# [01:17] <zewt> SamB: document.location.hashhash
# [01:18] <SamB> KevinMarks_: people have certainly been after such a thing for text/plain for ages
# [01:18] <KevinMarks_> quite
# [01:18] <SamB> zewt: well, but what would the "type" of that be?
# [01:18] <SamB> [(String, String)] ?
# [01:18] <SamB> Map String String ?
# [01:18] <zewt> not sure, seems not hard to define but probably not worth brainstorming at this point
# [01:18] <KevinMarks_> the html5 spec is liberally sprinkled with ids so you can link to almost any bit of it
# [01:18] <KevinMarks_> and that is hugely useful
# [01:18] <SamB> KevinMarks_: indeed
# [01:19] <SamB> not necessarily any bit you'd want to, but ...
# [01:19] <KevinMarks_> being able to do that for any web document is great
# [01:19] <zewt> changing url parsing and document.location makes this seem like a much bigger, heavier, more dangerous feature, compared to its value
# [01:19] <KevinMarks_> it doesn't change .location
# [01:19] <SamB> while we're on that topic, shouldn't there be some kind of browser UI for finding a nearby anchor?
# [01:19] <KevinMarks_> only target
# [01:19] <zewt> sigh
# [01:19] <JonathanNeal> Hixie: I would point to http://indiewebcamp.com/fragmention#Related_work and http://en.wikipedia.org/wiki/Fragment_identifier#Proposals are decent arguments against it being esoteric
# [01:20] <SamB> and making a you a URL for it?
# [01:20] <zewt> it does in a big chunk of the discussion for the last page
# [01:20] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [01:20] <SamB> zewt: last page?
# [01:20] * Joins: llkats (~llkats@2602:306:ce79:3a69:433:e330:a0b7:31d1)
# [01:20] <JonathanNeal> s/are/as
# [01:20] <zewt> the entire "change URL parsing" discussion is about changing .location
# [01:21] <KevinMarks_> yes, the ## stuff
# [01:21] * Quits: jwalden (~waldo@corp-nat.p2p.sfo1.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 27.0/20140203120101])
# [01:21] <KevinMarks_> that's why I say YAGNI on that
# [01:21] * Joins: jeffreyatw (~jeffreyat@66.194.1.26)
# [01:21] <Hixie> JonathanNeal: Put it this way. I have never heard non-web-heads (i.e. "real users") ask for this feature.
# [01:21] <zewt> please don't make up abbreviations on the spot and expect others to guess what they mean
# [01:21] <SamB> oh, I get it, "<zewt> it does in a big chunk [...]" is a response to "<KevinMarks_> it doesn't change .location"
# [01:22] <zewt> SamB: sometimes one wishes for threaded IRC :P
# [01:22] <Hixie> bbiab
# [01:22] <SamB> Hixie: why should only "real users" get features?
# [01:22] <KevinMarks_> you weren't in the Annotations meeting i was
# [01:22] <SamB> zewt: YAGNI isn't made up on the spot?
# [01:22] <SamB> it's in vera; no idea why not foldoc
# [01:23] <Hixie> SamB: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
# [01:23] <SamB> Hixie: point
# [01:25] <KevinMarks_> this workshop: http://www.w3.org/2014/04/annotation/
# [01:25] <zewt> my overall take is that changing URL parsing and document.location is a big, scary change that dwarfs the value of the change; the feature not working on a few pages that use hashes in unusual ways is lame but bearable (and expected--the "##" idea wasn't expected to work in every case); if people decide it's not bearable, better to drop it than to mess around with something so fundamental
# [01:25] <KevinMarks_> was where I heard use case after use case of people wanting more robust anchors into the web
# [01:25] <SamB> hmm
# [01:26] <zewt> my main issue with regular anchors is I can never find them; if browsers had a "copy link to this page at the most recent anchor" (so I didn't have to go hunt down a TOC link or open the inspector) they'd be a heck of a lot more usable
# [01:26] <KevinMarks_> yes
# [01:26] <zewt> that would help a lot without any platform changes
# [01:26] <KevinMarks_> but being able to point to the text is better
# [01:26] <SamB> for a moment I was pondering actually trying to allow xlink, but then I was like "but what would be in the address bar?" so yeah not going to work ...
# [01:26] <KevinMarks_> because that is what they are trying to do
# [01:27] <SamB> zewt: yeah, I just mentioned that above
# [01:27] <KevinMarks_> and in this case the address bar is very clear
# [01:27] <SamB> "shouldn't browsers have UI to find a handy anchor and make you a link"
# [01:27] <SamB> that's a paraphrase
# [01:28] <KevinMarks_> they are referring to the text not the anchor
# [01:29] <KevinMarks_> In effect, we can make you an anchor for what you select
# [01:30] <SamB> anyway, the amount of work involved here would make it an absolute requirement that any such change allow a whole namespace of such things, not just this one "fragmentions"
# [01:30] <zewt> we understand the difference
# [01:30] <SamB> KevinMarks_: I was talking about better UI to make links that work today
# [01:30] <SamB> and, well, probably also last decade
# [01:31] <SamB> by which I mean ~2004, not 2009
# [01:31] <KevinMarks_> so we'll stick to shipping a page of js that makes the browsers capable of doing this now then
# [01:31] <SamB> KevinMarks_: which of course makes you part of the problem
# [01:32] <SamB> in the sense that your scripts toes are among those that would need to be avoided in order to make such a change
# [01:32] <KevinMarks_> not if you make this change... :D
# [01:32] <SamB> well it sure won't happen quickly
# [01:33] <JonathanNeal> SamB: actually, I hate that problem too, so when I wrote the script, I built in a feature test.
# [01:34] <SamB> Hixie: so, um, does it make much difference what syntax he tries to use for this fragmentions thing? i.e. would it be better to use something like ##text= with the usual query-encoding?
# [01:34] <SamB> JonathanNeal: how does it test for the feature?
# [01:34] <KevinMarks_> http://sandbox.thewikies.com/fragmentions/example.html#phrases+as+anchors
# [01:34] <JonathanNeal> SamB: what you could fault me for is making a feature test for a feature that doesn’t exist. The best I could do is search window.location for a fragmention property.
# [01:34] <zewt> you could probably write to .hash and see if the location changes, but that'd be pretty intrusive
# [01:34] <KevinMarks_> http://sandbox.thewikies.com/fragmentions/example.html#readable+shortcuts
# [01:35] <SamB> JonathanNeal: pretty confident about the name, huh?
# [01:35] <JonathanNeal> in the same way that .hash is a partial, decoded version of .href, .fragmention is a partial, decoded version of .hash.
# [01:36] <KevinMarks_> you could see if target already matches what you were going to change it to?
# [01:36] <JonathanNeal> SamB: like I said, fault me for that.
# [01:36] <TabAtkins> zewt: Yeah, don't mess with .hash at all.
# [01:36] * Quits: jernoble|laptop (~jernoble@17.202.45.163) (Quit: Computer has gone to sleep.)
# [01:36] <TabAtkins> Just let .hash continue to reflect the entire hash, then have another k/v dict populated from the ## values, like the current .query.
# [01:36] <SamB> JonathanNeal: actually, I guess it's best if you don't really go anywhere near before some kind of consensus to use it would happen?
# [01:36] <JonathanNeal> TabAtkins: that is what I tried to do, effectively. (see above comment)
# [01:36] <zewt> TabAtkins: hixie's concern is that the feature wouldn't work on pages that use the hash literally (as in the "print the hash to a canvas" page)
# [01:37] <SamB> s/near/near ##/
# [01:37] <TabAtkins> zewt: What I just said *should* work on pages taht use the hash literally.
# [01:37] <zewt> i don't think that's web compat, though (or at least, not "web backwards-compatibility", which is the direction I usually think of it in)
# [01:37] <TabAtkins> That's why I suggested it. ^_^
# [01:37] <zewt> TabAtkins: not sure what you meant, then
# [01:37] <TabAtkins> If you want to use the hash literally, you just look at .hash.
# [01:37] <KevinMarks_> http://sandbox.thewikies.com/fragmentions/example.html#include+the+entire+text
# [01:37] <TabAtkins> Which is *the entire hash*, as it is today.
# [01:37] <JonathanNeal> SamB, that’s an interesting point, though, if one of us had not made a proof of concept, I’m curious where the discussion would have gone.
# [01:37] <SamB> TabAtkins: obviously whether to include it in .hash would merit further study
# [01:37] <KevinMarks_> those last few links are all calls for linking to text
# [01:38] <zewt> TabAtkins: the example was http://damowmow.com/playground/demos/fragment-identifiers/002.html##0271a91a-86a0-4773-b042-eb535834e0d8=hello
# [01:38] <SamB> hmm, this fragmentions thing does not work with script disabled ;-P
# [01:38] <zewt> TabAtkins: or to get rid of the weird example I made: http://damowmow.com/playground/demos/fragment-identifiers/002.html##search=hello
# [01:39] <zewt> TabAtkins: the feature would continue to be printed to the canvas, since the ##stuff still shows up in .hash
# [01:39] * Joins: seventh (seventh@209.99.57.66)
# [01:39] <KevinMarks_> JonathanNeal: I agree - your implementation made it clear that this worked and was useful
# [01:39] <TabAtkins> Yeah, that would give a .hash of "#search=hello". (Or "##search=hello", I forget whether .hash includes the initial #.)
# [01:39] <zewt> TabAtkins: i think we can live with that, FWIW
# [01:39] <SamB> so, would it be stupid to set up telemetry for ## ?
# [01:39] <TabAtkins> Whatever it does today.
# [01:39] <TabAtkins> But it woudl also give a .hashQuery of {search:["hello"]} or whatever.
# [01:39] <TabAtkins> zewt: So yeah, what you said.
# [01:39] <SamB> TabAtkins: hmm, so we don't want to allow repeated keys then?
# [01:40] <SamB> or ordering between keys
# [01:40] <zewt> TabAtkins: the ##text= idea was meant to 1: avoid collisions with links that already exist today, and 2: give programmers a way to use both this feature and their own stuff in hashes at the same time
# [01:40] <JonathanNeal> TabAtkins: today the hash contains the #, so, location.hash = 'hello'; location.hash // '#hello'
# [01:40] <TabAtkins> SamB: Note the value is an array, just like for query values.
# [01:40] <SamB> oh
# [01:40] <SamB> nevermind
# [01:40] <zewt> not to make this new feature work on every page, which it definitely won't
# [01:40] <TabAtkins> zewt: Not sure how waht you're saying is relevant to what I said.
# [01:41] <SamB> oh, well, that would still not allow different handling of ##text=foo##css=:bar and ##css=:bar##text=foo
# [01:41] <SamB> not that the former would ever make much sense ...
# [01:42] <TabAtkins> SamB: The URL object does track those differently, I think.
# [01:42] <zewt> SamB: i'd totally avoid repeated keys, the APIs you end up with for a multidict are uglier than for a simple dictionary for incredibly rare cases
# [01:42] <TabAtkins> (Or if it doesn't, then probably we dont' need that for hash queries either.)
# [01:42] <SamB> zewt: hmm
# [01:42] <zewt> (and even rarer for this stuff, at least for the potential uses we've discussed so far)
# [01:43] <zewt> basically this breaks the URL into three major parts: stuff for the server (path, query), client-side stuff for scripts (part of the hash), and client-side stuff for the browser (this stuff)
# [01:43] <SamB> (oh, btw: where I said XPath above I must have been thinking of XLink)
# [01:43] <SamB> zewt: browser or polyfill
# [01:43] <zewt> actually backing up, i'd start with: just expose this as a string
# [01:43] <KevinMarks_> JonathanNeal's script works fine with http://damowmow.com/playground/demos/fragment-identifiers/002.html
# [01:44] <SamB> zewt: hmm
# [01:44] <KevinMarks_> though you'd have to enter a lot of lines to see it do something
# [01:44] <SamB> zewt: so like .hashhash ?
# [01:44] <zewt> seems like a given that you want a string anyway (for reconstructing the URL in various ways); the real question is whether you *really* need a browser-parsed version of it (which I'd really leave off from this discussion, that's a detail)
# [01:44] <SamB> would be a string
# [01:44] <SamB> zewt: point, yes
# [01:45] <zewt> (we're already pretty far ahead of things talking about exposing it in location at all)
# [01:45] <SamB> you don't REALLY need a browser-parsed version
# [01:45] <JonathanNeal> zewt: re: "URL into three major parts", it already is, remember that #anchor will do something in your browser if you have <div id="anchor">.
# [01:45] <JonathanNeal> Sorry if you meant that and I just misunderstood you.
# [01:45] <zewt> JonathanNeal: sort of, but that's not a distinct part of the URL vs. script stuff
# [01:46] <KevinMarks_> o_O
# [01:46] * Quits: weinig (~weinig@17.114.216.47) (Quit: weinig)
# [01:46] <JonathanNeal> It is as distinct as hash search, no? At least, my library was written to do exactly what browsers do for hash anchors.
# [01:46] <KevinMarks_> exactly
# [01:47] <KevinMarks_> ID already owns this namespace
# [01:47] <zewt> today there's no way to differentiate between "the client's own special magic stuff in the hash" and "platform features in the hash"
# [01:47] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [01:47] <KevinMarks_> except the bit with spaces in
# [01:47] * Quits: othermaciej (~mjs@17.114.219.154) (Quit: othermaciej)
# [01:49] * Quits: lmcliste_ (~lmclister@192.150.10.210)
# [01:49] <zewt> nope, because pages can already put spaces in the hash for their own use
# [01:50] <zewt> of course, they can also put "##text=foo" in the hash, but one is less likely than the other
# [01:50] <SamB> http://url.spec.whatwg.org/#api seems kind of strangely-indented
# [01:51] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Remote host closed the connection)
# [01:51] <KevinMarks_> I love that my use case is a categorical collision and yours is a statistical argument
# [01:51] * Joins: llkats_ (~llkats@adsl-108-231-147-166.dsl.pltn13.sbcglobal.net)
# [01:51] <SamB> KevinMarks_: huh?
# [01:51] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [01:51] <KevinMarks_> if fragmentions had to have 10 words in, would you be happy then?
# [01:51] <KevinMarks_> 4?
# [01:52] <zewt> to restate: "http://foo.com#post10##text=foo" gives script authors a way to encode their own data into the url for AJAX/history API use ("post10"), and also use text search (or ID links, or other things) in the same URL; no other proposal so far does that
# [01:52] * Quits: llkats_ (~llkats@adsl-108-231-147-166.dsl.pltn13.sbcglobal.net) (Remote host closed the connection)
# [01:52] * Quits: llkats (~llkats@2602:306:ce79:3a69:433:e330:a0b7:31d1) (Ping timeout: 240 seconds)
# [01:53] * Joins: llkats (~llkats@2602:306:ce79:3a69:7841:a91f:a63f:5a92)
# [01:53] <KevinMarks_> that's not a use case
# [01:53] <zewt> ...
# [01:53] <SamB> zewt: and with ##css=, we could finally link to individual form controls in mediawiki preferences
# [01:54] <SamB> (or ##anchor or whatever)
# [01:54] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [01:54] <KevinMarks_> I say "lots of people want to link to the text of pages" you say "some mythical developer wants to combine the history api wiht text search
# [01:54] <zewt> wow, I've never been called mythical before
# [01:54] * Joins: weinig (~weinig@17.114.216.47)
# [01:55] <SamB> KevinMarks_: trust me, there are pages people will want to do this on that are not made up
# [01:55] <zewt> because I'd sure like to be able to write history API pages without breaking ID links, but it's not possible
# [01:55] * SamB goes looking for some apple docs ...
# [01:55] <KevinMarks_> aaron added fragmentions to media wiki in about 20 minutes
# [01:55] <KevinMarks_> it's handy
# [01:55] <SamB> KevinMarks_: that won't do what I just said though
# [01:56] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 240 seconds)
# [01:56] <SamB> especially considering that that part of the UI is multilingual
# [01:56] * Quits: weinig (~weinig@17.114.216.47) (Client Quit)
# [01:56] <KevinMarks_> yes it does: http://indiewebcamp.com/Special:Preferences##New+signature
# [01:57] * Joins: othermaciej (~mjs@17.114.219.154)
# [01:57] <KevinMarks_> you have to sign in, mind
# [01:57] <SamB> what if I have my UI set to klingon or something
# [01:57] <SamB> (obviously not actually klingon, and not actually me, but it does turn out that klingon has an ISO code and everything)
# [01:58] <KevinMarks_> whats the iso code for klingon?
# [01:58] <SamB> I think it's tlh
# [01:59] <SamB> anyway, consider e.g. https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/Introduction/Introduction.html#//apple_ref/doc/uid/TP30001066
# [01:59] <KevinMarks_> what's kn?
# [01:59] <KevinMarks_> that looks like klingon
# [02:00] <SamB> that's a fairly randomly chosen piece of documentation, but you can probably see that it's long enough that one might want to use something like fragmentions there
# [02:01] <KevinMarks_> http://indiewebcamp.com/Special:Preferences##ಇ-ಅಂಚೆ
# [02:02] <SamB> hmm, maybe that isn't the best example though because I guess the hash part of the URL is not terribly interesting ...
# [02:03] <zewt> apple doc urls are a nightmare
# [02:03] <SamB> yeah
# [02:03] * Joins: fishd_ (~darin@216.239.45.83)
# [02:03] <SamB> but not seemingly a good example of the problem :-(
# [02:03] <KevinMarks_> at least they stopped using the webobjects ones with colons in
# [02:04] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [02:05] <KevinMarks_> hm, actually the chrome fragmention plugin seems to work OK in that doc
# [02:06] <SamB> yeah, I remembered the fragments being more important there
# [02:06] <SamB> obviously I misremembered
# [02:06] * Joins: zama (zama@unaffiliated/stryx/x-3871776)
# [02:06] * Quits: fishd__ (~darin@216.239.45.66) (Ping timeout: 252 seconds)
# [02:07] <KevinMarks_> it certainly doesn't break their links
# [02:09] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [02:10] * Joins: hasather (~hasather@guest.schibsted.no)
# [02:14] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 252 seconds)
# [02:17] <SamB> (Oh, how would you link to something on the Beta tab on, say, mediawiki.org -- without knowing the UI language?)
# [02:19] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [02:19] * Joins: benwerd (~benwerd@75-101-52-42.dsl.static.sonic.net)
# [02:19] <MikeSmith> is there a downloadable version of Presto-based Opera still available?
# [02:20] * Quits: ambv_ (~ambv@206.108.217.134) (Quit: sys.exit(0) # computer went to sleep)
# [02:21] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [02:21] * Quits: llkats (~llkats@2602:306:ce79:3a69:7841:a91f:a63f:5a92) (Remote host closed the connection)
# [02:24] <MikeSmith> nm
# [02:24] <MikeSmith> Opera 12 I guess
# [02:25] * Joins: eric_carlson_ (~ericc@50.185.207.137)
# [02:25] * Quits: eric_carlson_ (~ericc@50.185.207.137) (Client Quit)
# [02:31] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [02:32] <KevinMarks_> SamB linking across languages is a tough usecase
# [02:32] <KevinMarks_> the person at the annotations mtg who knew most about ti was a biblical concordance speciallist
# [02:33] <KevinMarks_> and they have relatively well-defined cross-language anchors
# [02:33] <SamB> well, the easy way is to use the ID, isn't it?
# [02:33] <KevinMarks_> no, they have Matthew 12:18 type anchors
# [02:33] <KevinMarks_> the 12:18 is in the text, and the lookup the Book name, iirc
# [02:34] * SamB meant for the MW preferences thing
# [02:35] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 252 seconds)
# [02:36] <SamB> or, if we actualyl want stuff like what fragmentions is actually meant for, try using them on https://groups.google.com/forum/#!topic/linux.debian.project/LBCAsdfl_ws maybe?
# [02:37] * Joins: ojan_away (sid5519@gateway/web/irccloud.com/x-zuactafedroaubfx)
# [02:38] * Joins: falken__ (uid20729@gateway/web/irccloud.com/x-jqybceignjvpuoxj)
# [02:39] <SamB> (nevermind that you can't read that in elinks, despite there not really being any content there that it couldn't handle tolerably ...)
# [02:39] * Joins: tobie___ (sid5692@gateway/web/irccloud.com/x-hzyofphuadouwqzh)
# [02:40] * Joins: cwilso_____ (sid10206@gateway/web/irccloud.com/x-gcflbtzevmzkexer)
# [02:41] * Joins: daleharvey_ (sid513@gateway/web/irccloud.com/x-zprmlxodrvxfylji)
# [02:42] <KevinMarks_> is that an example of the hashbang antipattern?
# [02:44] * Quits: ojan (sid5519@gateway/web/irccloud.com/x-hrevpdmftkodcksp) (Read error: Connection reset by peer)
# [02:44] * ojan_away is now known as ojan
# [02:44] * Quits: tobie__ (sid5692@gateway/web/irccloud.com/x-rajrshfrxykhpnfn) (Ping timeout: 246 seconds)
# [02:44] * tobie___ is now known as tobie__
# [02:44] * Quits: jeffreyatw (~jeffreyat@66.194.1.26) (Ping timeout: 240 seconds)
# [02:44] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [02:45] * Joins: dfreedm_ (sid7859@gateway/web/irccloud.com/x-kypbbqldlthufsft)
# [02:46] * Joins: astearns_ (sid15080@gateway/web/irccloud.com/x-yqgdbiqyngkttrzv)
# [02:46] * Joins: sgalineau_ (sid26595@gateway/web/irccloud.com/x-vjjqtafjcdweuphq)
# [02:47] * Quits: falken_ (uid20729@gateway/web/irccloud.com/x-mlekzdswusvkmhit) (Ping timeout: 246 seconds)
# [02:47] * Quits: daleharvey (sid513@gateway/web/irccloud.com/x-idgyoemrvsgeaypg) (Ping timeout: 246 seconds)
# [02:47] * Quits: cwilso (sid10206@gateway/web/irccloud.com/x-otnyefcrouyzrqgw) (Ping timeout: 246 seconds)
# [02:47] * Quits: sgalineau (sid26595@gateway/web/irccloud.com/x-cfziidqehvwzlzqk) (Ping timeout: 246 seconds)
# [02:47] * Quits: Gege (gege@future.deferred.io) (Ping timeout: 246 seconds)
# [02:48] * Joins: Gege (~gege2@2001:470:1f1b:ed::2)
# [02:48] * Quits: dfreedm (sid7859@gateway/web/irccloud.com/x-bpcvgtbcvoaflylb) (Ping timeout: 246 seconds)
# [02:48] * Quits: astearns (sid15080@gateway/web/irccloud.com/x-mfrurxydsonaslkf) (Ping timeout: 246 seconds)
# [02:48] * falken__ is now known as falken_
# [02:48] * cwilso_____ is now known as cwilso
# [02:48] * sgalineau_ is now known as sgalineau
# [02:48] * daleharvey_ is now known as daleharvey
# [02:48] * dfreedm_ is now known as dfreedm
# [02:48] * astearns_ is now known as astearns
# [02:48] * Quits: Gege (~gege2@2001:470:1f1b:ed::2) (Ping timeout: 246 seconds)
# [02:49] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [02:50] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [02:51] * Joins: rniwa (~rniwa@17.202.43.222)
# [02:53] <zewt> "antipattern" is what people call things they don't like that they want to make sound bad, not something necessarily actually bad, so better not to call something an "antipattern" if you're not even sure if it is something or not :P
# [02:54] <tantek> yup that's just #! hashbang anti-pattern. Google Groups needs to fix that.
# [02:54] <SamB> KevinMarks_: it's an example of AJAX taken too far, period
# [02:55] <zewt> (nothing wrong with that url, though the "!" seems a bit pointless)
# [02:55] <SamB> #! might actually mitigate it somewhat for clients who have any idea what that means
# [02:56] <SamB> I've seen other pages that had several tabs which I think a non-JS browser would just render all of
# [02:56] <zewt> non-JS browsers are pretty irrelevant to the real world
# [02:56] <SamB> that's not quite as bad, but it'd still be a problem for fragmentions
# [02:58] <SamB> not so irrelevant that gmail doesn't support them ...
# [02:58] <SamB> ... though admittedly actually *getting* into basic HTML mode has had problems lately
# [02:58] <zewt> html in email isn't a browser
# [03:03] <KevinMarks_> now here's another variant: https://dl.dropboxusercontent.com/u/18852638/draft/silly/test.html##Brennan+Novak(Brennan+is+bnvk+on+#indieweb+and+#mailpile)
# [03:05] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [03:09] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
# [03:10] * Joins: hasather (~hasather@guest.schibsted.no)
# [03:12] <MikeSmith> TabAtkins: when you have a few minutes please let me know what should be added to the "CSS features" part of http://platform.html5.org/
# [03:14] <MikeSmith> and what if anything should be removed
# [03:15] * Joins: Gege (gege@future.deferred.io)
# [03:15] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 264 seconds)
# [03:26] * Joins: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net)
# [03:29] * Quits: SamB (~SamB@2001:470:1f07:57:b4ec:e904:4a30:8b28) (Read error: Connection reset by peer)
# [03:50] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Read error: Connection reset by peer)
# [03:52] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [03:56] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 252 seconds)
# [04:01] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [04:04] * Joins: KevinMarks (~yaaic@2607:fb90:509:2025:e6dc:6c5:3c7:6bf8)
# [04:05] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
# [04:06] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [04:06] <MikeSmith> Hixie: colors look nice
# [04:09] <Hixie> :-)
# [04:10] * Joins: bufferino (~yz@103.11.50.90)
# [04:11] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 276 seconds)
# [04:11] * Joins: hasather (~hasather@guest.schibsted.no)
# [04:12] * Quits: othermaciej (~mjs@17.114.219.154) (Quit: othermaciej)
# [04:13] * Joins: newtron (~newtron@69-196-129-59.dsl.teksavvy.com)
# [04:14] * Joins: jeremyzilar (~Adium@ool-4a5afb9b.dyn.optonline.net)
# [04:16] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 265 seconds)
# [04:18] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [04:25] * Quits: dwim (~dwim@210.94.41.89) (Remote host closed the connection)
# [04:26] * Quits: ivan`` (~ivan@unaffiliated/ivan/x-000001) (Ping timeout: 264 seconds)
# [04:29] * Joins: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au)
# [04:30] * Joins: ivan`` (~ivan@unaffiliated/ivan/x-000001)
# [04:34] * Quits: seventh (seventh@209.99.57.66) (Ping timeout: 240 seconds)
# [04:38] * Joins: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net)
# [04:46] <Hixie> i'm amused that chrome just can't handle the gradient on the html spec and gives up
# [04:46] <Hixie> firefox can't handle it well either, it turns into into four bands
# [04:46] <Hixie> which actually kinda looks cool
# [04:47] <Hixie> tempting to actually switch to that intentionally :-)
# [04:51] * Quits: benwerd (~benwerd@75-101-52-42.dsl.static.sonic.net) (Remote host closed the connection)
# [04:51] * Quits: jeremyzilar (~Adium@ool-4a5afb9b.dyn.optonline.net) (Quit: Leaving.)
# [04:55] * Joins: weinig (~weinig@98.234.191.242)
# [05:06] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [05:07] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
# [05:11] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
# [05:12] * Joins: hasather (~hasather@guest.schibsted.no)
# [05:13] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [05:17] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
# [05:23] * Quits: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [05:26] * Joins: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au)
# [05:27] * Quits: newtron (~newtron@69-196-129-59.dsl.teksavvy.com) (Remote host closed the connection)
# [05:27] * Joins: newtron (~newtron@69-196-129-59.dsl.teksavvy.com)
# [05:31] * Quits: newtron (~newtron@69-196-129-59.dsl.teksavvy.com) (Ping timeout: 240 seconds)
# [05:36] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [05:36] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [05:36] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-wspghimuqyvgjqez) (Quit: Connection closed for inactivity)
# [05:42] * Quits: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso) (Quit: eatsomeatso)
# [05:43] * Quits: tav (~tav`@host109-154-1-226.range109-154.btcentralplus.com) (Quit: tav)
# [05:49] * Quits: weinig (~weinig@98.234.191.242) (Quit: weinig)
# [05:53] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [05:54] * Joins: tav (~tav`@host109-154-1-226.range109-154.btcentralplus.com)
# [05:57] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 264 seconds)
# [05:58] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
# [06:07] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [06:12] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [06:13] * Joins: hasather (~hasather@guest.schibsted.no)
# [06:15] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [06:17] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
# [06:21] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
# [06:42] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
# [06:55] * Joins: niloy (~niloy@static-mum-182.58.194.59.mtnl.net.in)
# [06:55] <JonathanNeal> Will Chrome get HTML5 context menus? http://davidwalsh.name/html5-context-menu
# [06:56] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [07:00] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [07:01] <Hixie> looks like the spec splitter is broken
# [07:04] * Quits: tav (~tav`@host109-154-1-226.range109-154.btcentralplus.com) (Quit: tav)
# [07:08] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [07:12] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 265 seconds)
# [07:14] * Joins: hasather (~hasather@guest.schibsted.no)
# [07:18] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 252 seconds)
# [07:20] <TabAtkins> Hixie: The gradient works just fine on Chrome for me.
# [07:20] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [07:25] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [07:29] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [07:31] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 240 seconds)
# [07:32] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [07:36] <Hixie> TabAtkins: on teh single-page copy?
# [07:36] <TabAtkins> Oh, haven't looked.
# [07:37] <Hixie> works fine for me elsewhere
# [07:54] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [07:57] * Quits: hsivonen (~hsivonen@bugzilla.validator.nu) (Read error: Operation timed out)
# [07:58] * Joins: hsivonen (~hsivonen@bugzilla.validator.nu)
# [07:58] * Quits: Johnny- (~null@unaffiliated/johnny-) (Ping timeout: 252 seconds)
# [07:58] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 265 seconds)
# [07:59] * Joins: hasather (~hasather@guest.schibsted.no)
# [08:00] * Joins: zdobersek (~zan@81.17.27.234)
# [08:00] * Joins: Johnny- (~null@unaffiliated/johnny-)
# [08:03] * Quits: hasather (~hasather@guest.schibsted.no) (Read error: Connection reset by peer)
# [08:03] * Joins: hasather_ (~hasather@guest.schibsted.no)
# [08:08] * Quits: hasather_ (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
# [08:08] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [08:12] * Joins: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [08:14] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Remote host closed the connection)
# [08:15] * Joins: Ducki (~Ducki@137.116.197.171)
# [08:18] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [08:19] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:43] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [08:44] * Joins: markkes (~markkes@62.207.90.201)
# [08:49] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [08:54] <zcorpan> Hixie: that gradient is horrible :-P
# [09:00] * Joins: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net)
# [09:04] * Joins: hasather (~hasather@guest.schibsted.no)
# [09:05] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Read error: Connection reset by peer)
# [09:08] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 255 seconds)
# [09:14] * Joins: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net)
# [09:15] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Quit: Computer has gone to sleep.)
# [09:16] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [09:16] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [09:26] * Joins: Maurice` (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [09:26] * Joins: Ms2ger (~Ms2ger@91.180.172.211)
# [09:30] * Joins: hasather (~hasather@guest.schibsted.no)
# [09:31] * Quits: beowulf (~sstewart@host86-184-178-231.range86-184.btcentralplus.com) (Ping timeout: 252 seconds)
# [09:33] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 240 seconds)
# [09:33] <JakeA> Domenic_: response.body will be a readable stream in SW. However, we need something akin to responseText from XHR
# [09:33] <JakeA> Domenic_: async of course
# [09:34] <JakeA> Domenic_: Are you planning on adding helpers like this to streams?
# [09:34] * Joins: jensnockert (~jensnocke@host-95-199-11-4.mobileonline.telia.com)
# [09:34] <JakeA> Domenic_: Otherwise we'll just add them to our Response objects
# [09:49] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
# [09:49] * Joins: Kolombiken (~Adium@gateway.creuna.se)
# [09:54] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [09:57] <mathiasbynens> Hixie: http://validators.whatwg.org/ still doesn’t resolve for me – sure that fix worked?
# [09:59] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 264 seconds)
# [10:03] * Quits: jensnockert (~jensnocke@host-95-199-11-4.mobileonline.telia.com) (Remote host closed the connection)
# [10:06] <JakeA> http://www.downforeveryoneorjustme.com/http://validators.whatwg.org/
# [10:06] <JakeA> It's down for me too
# [10:07] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Read error: Connection reset by peer)
# [10:10] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [10:11] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [10:13] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [10:14] * Joins: xiinotulp (~plutoniix@node-m1n.pool-101-108.dynamic.totbb.net)
# [10:16] * Joins: charl_ (~charl@2001:67c:2564:524:c194:f651:9d18:9b88)
# [10:18] * Quits: plutoniix (~plutoniix@node-zur.pool-180-180.dynamic.totbb.net) (Ping timeout: 252 seconds)
# [10:20] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
# [10:26] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [10:27] * Joins: annevk (~annevk@5ED376C5.cm-7-4b.dynamic.ziggo.nl)
# [10:30] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [10:32] <JakeA> https://twitter.com/bug_facts/status/457712371616608256
# [10:34] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [10:34] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 252 seconds)
# [10:35] <JakeA> Sooooo, posted THAT in the wrong channel
# [10:35] <JakeA> Enjoy it anyway
# [10:37] * Joins: cheron (~cheron@unaffiliated/cheron)
# [10:47] <annevk> When is someone going to take ownership of IDL?
# [10:47] <annevk> We really need the array issues and such resolved
# [10:47] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
# [10:48] <Ms2ger> When you do
# [10:48] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [10:49] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [10:50] <annevk> JakeA: I think we should have helpers on streams
# [10:50] <annevk> JakeA: e.g. a TransformStream of sorts that converts bytes to text
# [10:50] <annevk> JakeA: although we probably need helpers on Response as well given that the decoding depends heavily on other properties of the Response object
# [10:51] <JakeA> annevk: yeah, I guess you couldn't toBlob a stream because there's no content-type
# [10:52] * Quits: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 264 seconds)
# [10:52] <JakeA> annevk: I think SW Response will need a getBodyText helper too, although we can deprecate it when streams land
# [10:53] <JakeA> annevk: filed https://github.com/slightlyoff/ServiceWorker/issues/251
# [10:53] <annevk> JakeA: you can't just add / remove methods...
# [10:53] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 252 seconds)
# [10:53] <annevk> JakeA: getBodyText() sounds a lot like Java
# [10:54] <JakeA> annevk: open to other names. Needs to return a promise. Problem is, toString() is taken :D
# [10:55] * Joins: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [10:55] <annevk> JakeA: don't really have great suggestions either
# [10:55] <JakeA> asText()
# [10:55] <annevk> JakeA: <canvas> has toBlob iirc
# [10:56] <JakeA> Sounds like Aztecs
# [10:56] <annevk> asString might be okay
# [10:56] <JakeA> annevk: toBlob and asString?
# [10:56] <annevk> or bodyToString() hmm
# [10:59] <JakeA> annevk: to(type).then()
# [10:59] <annevk> JakeA: similar to responseType?
# [10:59] <annevk> JakeA: not half bad
# [10:59] <JakeA> annevk: that's what I'm thinking
# [10:59] * Joins: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net)
# [11:03] <smaug____> annevk: how is nobody not maintaining idl?
# [11:03] <smaug____> s/not//
# [11:03] <annevk> smaug____: I don't know, it's just not happening
# [11:04] <annevk> smaug____: I think getting it up to speed would be at least several months of fulltime work and nobody has taken the time
# [11:04] <JakeA> more like ID-hell amirite? *holds hand up waiting for high-five*
# [11:04] <smaug____> hmm, I thought it has been updated when needed
# [11:04] * Joins: Lachy (~Lachy@213.166.174.2)
# [11:05] <annevk> https://www.w3.org/Bugs/Public/buglist.cgi?component=WebIDL&product=WebAppsWG&;resolution=--- lists 84 bugs and quite a few are larger issues
# [11:08] <smaug____> is there annotation for read only array
# [11:09] <smaug____> since I guess that is what we want for event.path
# [11:09] <smaug____> or Gecko's [frozen]
# [11:09] <annevk> It seems what people argue for is that we should simply return a mutable array
# [11:09] <annevk> A JavaScript Array object
# [11:12] <smaug____> well, for event.path is should be frozen Array
# [11:13] <smaug____> that is just a JS thing
# [11:13] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 252 seconds)
# [11:13] <annevk> Again, Domenic_, dherman, et al, argue it should not be frozen
# [11:17] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [11:20] * Joins: MutantMahesh (74cbe08a@gateway/web/freenode/ip.116.203.224.138)
# [11:20] * Quits: MutantMahesh (74cbe08a@gateway/web/freenode/ip.116.203.224.138) (Changing host)
# [11:20] * Joins: MutantMahesh (74cbe08a@unaffiliated/msankhala)
# [11:20] * Quits: MutantMahesh (74cbe08a@unaffiliated/msankhala) (Changing host)
# [11:20] * Joins: MutantMahesh (74cbe08a@gateway/web/freenode/ip.116.203.224.138)
# [11:23] * Joins: Ducki (~Ducki@137.116.197.171)
# [11:38] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
# [11:43] * Quits: CvP (~CvP@27.147.198.50) (Ping timeout: 255 seconds)
# [11:45] * xiinotulp is now known as plutoniix
# [11:50] * Joins: Lachy_ (~Lachy@213.166.174.2)
# [11:51] <jgraham> annevk: If you want those input tests fixed your should review https://critic.hoppipolla.co.uk/r/1370
# [11:51] <jgraham> I'm not sure it's right
# [11:51] * Quits: Lachy (~Lachy@213.166.174.2) (Read error: Connection reset by peer)
# [11:53] <annevk> jgraham: looks legit, but https://github.com/w3c/web-platform-tests/pull/928#discussion_r11965914
# [11:54] * Joins: adactio (~adactio@212.42.170.181)
# [11:55] <jgraham> Yeah, I wondered about that
# [11:55] <annevk> jgraham: I think per spec you can make it dirty by input.value = input.value
# [11:55] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [11:55] <jgraham> I guess I should find a way to sort the few useful messages from the torent of spam I get from GitHub
# [11:56] <annevk> I just found out I missed pull requests going back six months
# [11:56] <jgraham> annevk: Doing input.value += "a"; input.value = input.value.slice(0, input.value.length - 1) or something seems better
# [11:57] <jgraham> In the sense that I don't really trust browsers to get this right in the first case
# [11:57] <annevk> jgraham: because?
# [11:57] <annevk> I guess it depends on what you want to test
# [11:57] <annevk> But in that case I'd just do temp = input.value; input.value = "x"; input.value = temp
# [11:58] <annevk> As the slice trickery makes it look complicated
# [11:58] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Read error: Operation timed out)
# [11:59] <jgraham> annevk: Curiously that was almost exactly what I had just written :)
# [12:00] <jgraham> Pushed to the review
# [12:00] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [12:01] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
# [12:02] <annevk> reviewed
# [12:03] <jgraham> Thanks
# [12:04] <annevk> I wonder what the deal with the gradient is
# [12:13] * Quits: benvie_ (~bbenvie@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
# [12:14] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Quit: Computer has gone to sleep.)
# [12:16] <jgraham> Where is this gradient?
# [12:16] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [12:16] <Ms2ger> Down
# [12:17] <jgraham> Oh wait, I wasn't getting the new stylesheets
# [12:18] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 276 seconds)
# [12:18] <jgraham> Well this seems to be exposing bugs in Gecko in a way that make the spec more or less unusuable
# [12:18] * Quits: SonicX (~quassel@ip98-180-46-147.ga.at.cox.net) (Remote host closed the connection)
# [12:19] <Ms2ger> jgraham, oh?
# [12:19] <Ms2ger> Oh wow, that's ugly
# [12:20] <jgraham> http://imgur.com/NkwmZz3
# [12:22] <jgraham> On the multipage spec it works OK
# [12:22] <Ms2ger> Ah
# [12:22] <jgraham> But I really wish it didn't
# [12:22] <annevk> hsivonen: whenever I hear you talk about crypto, it kind of sounds like we need a "Crypto Standard"
# [12:23] <jgraham> Also most of the text in the boxes at the top overflows
# [12:25] <annevk> hsivonen: I'm not volunteering btw
# [12:25] <zcorpan> Hixie: i don't know if you're done with the review script, but currently it seems somewhat broken to me. if i click "more..." all that happens is that that button is replaced with a "hide" button, and clicking that makes the whole thing non-functional and no way to get it back without deleting the cookie
# [12:30] * Quits: davve (~user@83.218.67.123) (Remote host closed the connection)
# [12:53] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [12:59] <smaug____> why w3c bugzilla doesn't send all the bugmail it should :/
# [13:00] <annevk> smaug____: what are you missing out on?
# [13:01] <smaug____> comments from bug 25412
# [13:01] <smaug____> but reading those now
# [13:02] <annevk> :/
# [13:04] <Ms2ger> MikeSmith, ^
# [13:04] <annevk> so JakeA under http/https in http://fetch.spec.whatwg.org/#concept-basic-fetch we alternate on service worker / no service worker
# [13:05] <annevk> JakeA: a response from the service worker will still have all the checks a HTTP response has too
# [13:05] <annevk> JakeA: e.g. 301, 401
# [13:05] <annevk> JakeA: service worker only intercepts http/https traffic
# [13:06] <annevk> JakeA: not data or blob URLs
# [13:07] <JakeA> annevk: would SW branch at step 7 of the http(s) steps?
# [13:08] * Quits: toyoshiAw (~toyoshim@yuri.twintail.org) (Ping timeout: 245 seconds)
# [13:08] <annevk> JakeA: of the initial set of steps, something like that
# [13:08] * Joins: toyoshiAw (~toyoshim@yuri.twintail.org)
# [13:09] <annevk> JakeA: we haven't really detailed how uploading works
# [13:09] <annevk> JakeA: presumably the request would arrive before all the data gets there
# [13:10] <annevk> JakeA: I've been thinking of factoring out "upgrading a request to a proper HTTP request", "making an http request", "creating a response from an http response", etc.
# [13:10] <JakeA> annevk: the request body in SW would be a stream. Need to get my head around what we can & can't do, and which things should tee automatically
# [13:10] <annevk> JakeA: to make the flow a bit more apparant
# [13:10] <MikeSmith> smaug____: dunno why it wouldn't be sending you bugmail as expected
# [13:10] <annevk> JakeA: currently it's a bunch of paragraphs intertwined with steps, not the best
# [13:11] <JakeA> annevk: Good to have that flow there though
# [13:11] <JakeA> annevk: It's like… this SW thing might actually happen
# [13:11] <MikeSmith> smaug____: I'm receiving bugmail from bug 25412 fine
# [13:12] <MikeSmith> about 6 messages from the last two days
# [13:13] <annevk> JakeA: yeah, took me a while to realize how badly SW needs Fetch, glad I wrote it
# [13:13] <MikeSmith> ーMy main criterion is "A C++ implementation of this algorithm will not crash"
# [13:14] <annevk> MikeSmith: for a tombstone
# [13:14] <MikeSmith> heh
# [13:15] * Quits: niloy (~niloy@static-mum-182.58.194.59.mtnl.net.in) (Ping timeout: 264 seconds)
# [13:16] <MikeSmith> in other news for some bizarre reason my Opera 12 won't connect to whatwg.org nor google.com
# [13:19] <jgraham> Opera has good taste in gradients and so won't let you see whatwg specs, or other properties with which Hixie has a professional association
# [13:19] <MikeSmith> haha
# [13:20] <MikeSmith> I like that gradient
# [13:20] * Quits: Ms2ger (~Ms2ger@91.180.172.211) (Quit: bbl)
# [13:21] * Joins: dwim (~dwim@210.94.41.89)
# [13:24] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [13:24] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [13:26] * Joins: niloy (~niloy@static-mum-182.58.166.15.mtnl.net.in)
# [13:29] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 265 seconds)
# [13:29] * Quits: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Remote host closed the connection)
# [13:35] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
# [13:37] * Quits: bufferino (~yz@103.11.50.90) (Remote host closed the connection)
# [13:39] * Quits: charl_ (~charl@2001:67c:2564:524:c194:f651:9d18:9b88) (Quit: leaving)
# [13:39] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [13:40] * Quits: niloy (~niloy@static-mum-182.58.166.15.mtnl.net.in) (Ping timeout: 252 seconds)
# [13:41] * Quits: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [13:45] * Joins: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au)
# [13:45] * Quits: dylanlindgren (~kartstar@60-241-188-143.static.tpgi.com.au) (Remote host closed the connection)
# [13:45] <smaug____> MikeSmith: I _think_ the same issue with w3 bugmail has happened before
# [13:45] <smaug____> oh well
# [13:45] * Joins: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso)
# [13:56] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [13:56] * Joins: niloy (~niloy@static-mum-182.58.170.238.mtnl.net.in)
# [14:01] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 276 seconds)
# [14:02] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [14:02] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Client Quit)
# [14:07] * Quits: niloy (~niloy@static-mum-182.58.170.238.mtnl.net.in) (Ping timeout: 252 seconds)
# [14:10] * Joins: tj_vantoll (~Adium@2601:4:5380:eba:2502:8095:8d3a:ed7d)
# [14:12] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
# [14:18] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [14:18] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [14:18] * Joins: scor (~scor@drupal.org/user/52142/view)
# [14:19] <tobie__> slightlyoff: hey, what are you using to write the service-worker spec? It's totally screwing up my toolchain. :(
# [14:21] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [14:22] * Quits: zdobersek (~zan@81.17.27.234) (Ping timeout: 240 seconds)
# [14:23] * Joins: niloy (~niloy@static-mum-182.58.170.238.mtnl.net.in)
# [14:25] * Joins: zdobersek (~zan@109.201.154.158)
# [14:26] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-mvcuxcggemjspxif)
# [14:28] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 276 seconds)
# [14:31] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [14:31] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [14:31] * Joins: scor (~scor@drupal.org/user/52142/view)
# [14:40] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [14:43] * Joins: newtron (~newtron@199.71.174.203)
# [14:44] * Quits: KevinMarks (~yaaic@2607:fb90:509:2025:e6dc:6c5:3c7:6bf8) (Remote host closed the connection)
# [14:48] <zcorpan> yay errata... https://www.w3.org/Bugs/Public/show_bug.cgi?id=25290
# [14:50] * Quits: niloy (~niloy@static-mum-182.58.170.238.mtnl.net.in) (Ping timeout: 264 seconds)
# [14:53] * Joins: Ms2ger (~Ms2ger@nata241.ugent.be)
# [15:03] * Joins: niloy (~niloy@static-mum-182.58.211.142.mtnl.net.in)
# [15:03] <annevk> tobie__: all the goo.gl URLs also...
# [15:03] <annevk> not sure what is going on there
# [15:04] * Joins: jensnockert (~jensnocke@ip123-237.wireless.lu.se)
# [15:05] <zcorpan> google, try switching it off and on again
# [15:10] * Joins: foxtrotwhiskey (~foxtrotwh@192-63-2457.unisys.com)
# [15:16] <Domenic_> JakeA: you plan to buffer the entire response body in memory? O_O that defeats the purpose of streaming it.
# [15:17] <zcorpan> MikeSmith: looks like v.nu never implemented the "xml" restriction for <embed>
# [15:17] <annevk> Domenic_: I think sometimes getting the response as a single string is fine
# [15:17] <Domenic_> annevk: JakeA: yes definitely a TransformStream converting ArrayBuffer to text is in the plan
# [15:17] <annevk> Domenic_: e.g. if you know it's small
# [15:17] <JakeA> Domenic_: Yes, the response may be json for instance
# [15:17] <zcorpan> MikeSmith: but it only gives a warning for foo:bar foo,bar etc, rather than an error
# [15:18] <Domenic_> JakeA: annevk: OK, but ... if you're going to buffer the full thing anyway, then don't bother making it a stream
# [15:18] <JakeA> Domenic_: This would be developer choice
# [15:18] <JakeA> Domenic_: We give them a response object with a stream for the body
# [15:18] <Domenic_> JakeA: no it's not. If the computer is buffering it all, then having it as a stream is pointless.
# [15:18] <annevk> Domenic_: there's a big problem with Response.prototype.body and a TransformStream
# [15:19] <annevk> Domenic_: you need other data from the Response to properly do it
# [15:19] <JakeA> Domenic_: But we want to make it non-trivial for them to get the whole response body, if that's what they want
# [15:19] <annevk> JakeA: there's a point to be made that as with XMLHttpRequest, the choice for what datatype you want is to be made upfront
# [15:19] <tobie__> Agree with annevk.
# [15:19] <Domenic_> JakeA: that's easy. readToEnd(Response.prototype.body)
# [15:20] <tobie__> + consistency
# [15:20] <Domenic_> readToEnd is a reusable function that works with *all* streams
# [15:20] <Domenic_> err, readToEnd(response.body)
# [15:20] <JakeA> Where does that method live?
# [15:20] <Domenic_> npm?
# [15:20] <JakeA> :(
# [15:21] <Domenic_> I dunno, we could add a global.streamHelpers namespace
# [15:21] <JakeA> annevk: Maybe response.body shouldn't be a stream at all, and you'd get one via .to('stream')
# [15:21] <Domenic_> annevk: you need headers, sure. but the body stream and the headers are separate
# [15:21] <annevk> brb
# [15:22] <Domenic_> annevk: In Node: var request = getThingy(); request.on('response', function (response) { console.log(response.headers); response.body.pipe(process.stdout); })
# [15:22] <Domenic_> Now I understand if there's a sequencing problem here
# [15:22] * Joins: TallTed (~Thud@63.119.36.36)
# [15:23] <Domenic_> i.e. if streams will be done/implemented after service workers (which seems possible, perhaps probable)
# [15:23] <Domenic_> and you need something to hold you over in the meantime
# [15:23] <Domenic_> but it will be redundant after streams land
# [15:23] <JakeA> Domenic_: We've already got .toBlob, probably going to switch that to .to(type)
# [15:23] <Domenic_> because nobody is going to want to use service worker's idiosyncratic way of buffering a whole stream and converting it to text
# [15:24] <Domenic_> what does .to(type) return
# [15:24] <JakeA> promise
# [15:24] <Domenic_> for?
# [15:24] <JakeA> depends on type
# [15:24] <Domenic_> so promise for stream for example?
# [15:25] <Domenic_> seems bad
# [15:25] <Domenic_> here would be my vision
# [15:25] <JakeA> Could be, although I think it's still better to reserve .body for the stream
# [15:25] <Domenic_> nobody uses blobs ever
# [15:25] <zewt> (what)
# [15:26] <Domenic_> .body is a stream, when streams land
# [15:26] <Domenic_> .to('arraybuffer') is conceptually readToEnd(response.body).then(concatAllArrayBufferSegmentsIntoOneGiantArrayBuffer)
# [15:26] <JakeA> Domenic_: "nobody is going to want to use sw's way of buffering a whole stream to text" Really, so if I want to get some JSON from a request, people won't want to do response.to('text').then(function(text) {}), they'd rather have to npm install something to do the same thing?
# [15:26] <zewt> the to(type) thing is ugly, don't do that
# [15:27] <Domenic_> .to('string') is conceptually readToEnd(response.body.pipeThrough(new TextDecoderStream('utf8'))).then(concatAllStrings)
# [15:27] <Domenic_> JakeA: yes, because the thing they install from npm will work with *any* stream
# [15:28] <JakeA> "People won't use querySelectorAll, because they can just import Sizzle"
# [15:28] <Domenic_> False analogy
# [15:28] <Domenic_> It would be as if you had a QSA that only worked on SVG
# [15:28] <Domenic_> and Sizzle worked on any DOM
# [15:29] <Domenic_> oh and implicit in that vision was that response.body is a stream of arraybuffers because that is the primitive
# [15:30] <JakeA> Well in this case, Sizzle works in more browsers than QSA
# [15:30] * Quits: jensnockert (~jensnocke@ip123-237.wireless.lu.se) (Remote host closed the connection)
# [15:30] <Domenic_> we're talking about the far-future
# [15:30] <Domenic_> where both streams and SW are there
# [15:30] <Domenic_> so people are now faced with a choice
# [15:30] <Domenic_> something that they have to remember to look up for SW
# [15:30] <Domenic_> or something that works for every stream in the same way
# [15:31] <Domenic_> and that they already use for lots of other things in their code
# [15:32] <JakeA> Hmm, this is a lot of future-prediction. Aside from that, SW is likely to land before streams, and we need to offer a way for people to get at response/request bodies
# [15:32] <Domenic_> yes, as i said, that's fine. there is a sequencing problem. but they will be conceptually vestigal after streams land, and---i predict---perceived as legacy vestiges.
# [15:32] <JakeA> We've reserved .body for a readable stream
# [15:33] <Domenic_> yay :)
# [15:33] <JakeA> I'm not confident in that prediction, but it doesn't matter
# [15:33] <Domenic_> agreed
# [15:34] <Domenic_> i would urge you to not have any blobs in new APIs and just use ArrayBuffers
# [15:34] <Domenic_> i might be missing something. but ArrayBuffers are JS's binary type.
# [15:35] <zewt> not a good suggestion; both Blobs and ArrayBuffers are useful and serve different purposes
# [15:35] <Domenic_> and blobs have lots of problems regarding racy weak-ref sematnics
# [15:35] <zewt> no they don't...
# [15:35] <Domenic_> zewt: educate me. what purpose do Blobs serve that ArrayBuffers do not serve.
# [15:35] <JakeA> zewt: What's wrong with .to(type)? The intention is to offer something like .responseType and .response in XHR, but not that awful
# [15:35] <Domenic_> yes, they do. we were just going over them in TAG.
# [15:36] <Domenic_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081
# [15:36] <zewt> being able to represent data that's stored on disk, which can't be accessed synchronously, and (as a corrolary to that) being able to represent large blocks of data which need to be splashed to disk
# [15:36] <Domenic_> The former is Promise<ArrayBuffer>
# [15:36] <Domenic_> the latter is arrayBuffer
# [15:37] <zewt> blob reading is underdefined, but that's not an inherent problem with blobs themselves (and it's being worked on)
# [15:37] <zewt> that doesn't make sense at all
# [15:38] <tobie__> JakeA: why `to("type")` instead of `toType`?
# [15:38] <zewt> if you get a File from a user via <input>, you don't want a callback system wrapping ArrayBuffer, you want a File (a Blob)
# [15:38] <Domenic_> what purposes does a File serve that an ArrayBuffer does not.
# [15:38] <Ms2ger> .name
# [15:39] <Domenic_> { name, data } done
# [15:39] <zewt> structured clone wouldn't work, which things like postMessage and IndexedDB depend on
# [15:39] <Domenic_> structured clone works fine with ArrayBuffers
# [15:39] <Domenic_> and works fine with shallow objects containing arraybuffers
# [15:39] <zewt> it seems like you don't have a basic understanding of what Blob is if you think it can be replaced with a callback to ArrayBuffer
# [15:39] <Domenic_> that's possible, but nobody here is saying anything otherwise
# [15:40] <Domenic_> it appears to be a binary data type with strictly less features than arraybuffer
# [15:40] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [15:41] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [15:41] <zewt> if you have a File pointing to a user-space file, you can stash the File object in History API (via structured clone), and reload it later after the session is restored, regaining access to the file (as long as it hasn't changed), without the UA having to make a deep copy of the file
# [15:41] <JakeA> tobie__: That's the other option, but if they're going to be legacy (as Domenic_) suggests, I'd rather have one method than more than one. Also, naming the function that gives you a string is tough :D
# [15:41] * Quits: adactio (~adactio@212.42.170.181) (Quit: adactio)
# [15:41] <zewt> i don't begin to see how that could map to a callback to a bunch of ArrayBuffers
# [15:42] <zewt> you can seek into a Blob to read an arbitrary subset, without reading unwanted stuff from disk; same
# [15:42] <Domenic_> zewt: ArrayBuffers and blobs are both things that can be transferred without making deep copies. What about blobs gives them this capability that you claim array buffers don't have?
# [15:43] <Domenic_> hmm, seeking is interesting. thanks, that is compelling. although it sounds like the concept of "file handle" and "binary data" have been conflated into the blob concept.
# [15:44] <zewt> if you store a File pointing to a user's document, the UA can simply internally store something like { type: "File", path: "c:/Documents/resume.txt", mtime: 12345 /* don't allow access if the mtime changes */ }, and later restore the File from that
# [15:44] <Domenic_> ok, so *File*s have special capabilities
# [15:44] <Domenic_> *Blob*s do not
# [15:44] <zewt> no, File == Blob, except for a bit of extra data (the filename)
# [15:44] <Domenic_> And that's still an optimization
# [15:44] <zewt> (i think they should be the same type)
# [15:44] * Joins: boogyman (~boogyman@142.196.161.32)
# [15:44] * Quits: boogyman (~boogyman@142.196.161.32) (Changing host)
# [15:44] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [15:44] <Domenic_> You could do the same with a file-backed arraybuffer
# [15:45] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [15:45] <zewt> not preemptively reading or making a copy of a 500 GB file from disk is not an optimization in any practical sense
# [15:45] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 252 seconds)
# [15:45] <Domenic_> file handles as a use case is interesting, i agree
# [15:45] <zewt> (okay, too many zeroes in that example)
# [15:45] <Domenic_> if i think of the only use case for blobs as being to represent seekable file handles, that's fine
# [15:46] <Domenic_> but e.g. using them to represent http responses is just weird
# [15:46] <zewt> depends on the case
# [15:47] <zewt> i agree there are fewer cases where it's optimal for that
# [15:47] <Domenic_> (i appreciate you being willing to stick with me until i got it.)
# [15:47] <zewt> only a few more minutes before I have to head to work, so I have a time cap :)
# [15:48] <zewt> there are probably better examples, but: reading a 100 MB archive from the server (say, game data), then reading data out of it (loading textures for the game)
# [15:49] <zewt> with Blob, the UA can read the big file to disk (it may not even have enough memory to store all that live); when you slice out the pieces you need it reads just the data you ask for
# [15:49] <zewt> ArrayBuffer can never stash data on disk, because it can be accessed synchronously
# [15:50] <Domenic_> with streams, you get to choose explicitly ;)
# [15:50] <zewt> one other thing Blob allows is shallow copies when posting to Workers, since it's immutable (ArrayBuffer *might* be able to do that, if there was a way to mark it read-only...)
# [15:50] <zewt> choosing that should be up to the UA (which knows how much memory it has, etc)
# [15:50] <Domenic_> ArrayBuffers are transferable already
# [15:51] <zewt> transferable isn't a shallow copy, it's moving the data outright
# [15:51] <Domenic_> Ah I see
# [15:51] <zewt> you can post a Blob to 10 workers, say to give a copy of data to a bunch of helpers without making 10 full copies
# [15:53] <Domenic_> frozen arraybuffers are a thing, yeah. but i doubt UAs do the shallow copy today
# [15:54] <Domenic_> plus lots of people hate freeze because it only works in certain specific cases. ArrayBuffers happen to be one of those cases, but the distaste remains.
# [15:54] <annevk> Domenic_: what I meant was that the headers influence the processing of the body
# [15:55] <annevk> Domenic_: so if you just pipe the body, you lose things such as encoding, MIME type
# [15:56] * Quits: niloy (~niloy@static-mum-182.58.211.142.mtnl.net.in) (Ping timeout: 240 seconds)
# [15:57] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [15:59] <Domenic_> annevk: that's a good point. there are workarounds of course but you would ideally want `res.body.pipeThrough(new AutoTextDecoder())` to be able to consult the headers. Instead of e.g. `res.body.pipeThrough(new TextDecoder(res.headers.get('Content-Encoding')))` (and I assume that the defaulting logic for that if no header is supplied is some horrendeous
# [15:59] <Domenic_> encoding-spec thing.)
# [15:59] <zewt> cringe
# [16:01] * Quits: MutantMahesh (74cbe08a@gateway/web/freenode/ip.116.203.224.138) (Ping timeout: 240 seconds)
# [16:02] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 276 seconds)
# [16:02] <annevk> Domenic_: yeah, a Blob has that advantage over a stream or ArrayBuffer
# [16:02] <annevk> Domenic_: it carries a MIME type with an optional charset parameter
# [16:03] <zewt> annevk: strictly speaking, ArrayBuffer could carry any of the metadata that Blob and File do
# [16:03] <annevk> Yeah, a Blob could be a promise for an ArrayBuffer I suppose, except for the readonly aspect
# [16:03] <zewt> (which might not be a bad idea, to bring the data models closer together)
# [16:04] <zewt> (though I'd really try to merge File down into Blob first)
# [16:05] * Joins: bufferino (~bufferino@bb115-66-4-98.singnet.com.sg)
# [16:05] * Quits: bufferino (~bufferino@bb115-66-4-98.singnet.com.sg) (Changing host)
# [16:05] * Joins: bufferino (~bufferino@unaffiliated/bufferino)
# [16:05] <Domenic_> It sounds like promise for ArrayBuffer doesn't have seeking.
# [16:06] <zewt> also compositing blobs together is easy and efficient
# [16:08] <annevk> A blob sucks though
# [16:08] <annevk> The biggest problem is the fixed size
# [16:09] <zcorpan> aaargh. i spent so long debugging why there were 0 tests run. turned out i forgot setup({explicit_done:true}) and created my tests onload :-(
# [16:09] <annevk> And synchronous availability of that size
# [16:09] <zewt> blobs represent immutable data, so it's fine that it's fixed, but yes, it's lame that the property is sync
# [16:10] * Quits: LazerBeak (~Lazerbeak@unafffiliated/lazerbeak) (Ping timeout: 264 seconds)
# [16:12] <jgraham> zcorpan: :(
# [16:12] <jgraham> Maybe if there were no tests it should give some helpful hints
# [16:13] <zcorpan> or if it tries to create tests after the harness thinks it's done?
# [16:14] <annevk> JakeA: maybe we should not use fetch() for the API where you need to read the response
# [16:14] * Joins: josemanuel (~josemanue@135.196.221.87.dynamic.jazztel.es)
# [16:14] <annevk> JakeA: but instead something like fetchJSON()
# [16:15] <annevk> JakeA: or fetchString()
# [16:15] * Joins: CvP (~CvP@27.147.198.50)
# [16:15] * Quits: zdobersek (~zan@109.201.154.158) (Quit: Leaving.)
# [16:15] * Joins: zdobersek (~zan@109.201.154.158)
# [16:15] <annevk> JakeA: and those would take care of doing the proper decoding and just hand you back a promise with the JSON object or string (or maybe something slightly more complicated that also exposes some other data from the response)
# [16:16] <JakeA> annevk: Do those methods mask the status etc of the request?
# [16:17] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [16:17] <annevk> JakeA: response?
# [16:17] <annevk> JakeA: depends on what we want
# [16:17] <JakeA> yes, sorry
# [16:17] <Domenic_> annevk: that makes a decent amount of sense to me given that it encapsulates a lot of encoding-spec and fetch-spec complexity
# [16:18] <Domenic_> e.g. i assume fetchString() is actually quite a lot of code on top of raw fetchArrayBufferSegments()
# [16:19] <annevk> It might not be that much as I'd force it to be utf-8
# [16:19] <Domenic_> haha
# [16:20] <Domenic_> General comment: I don't mean to push streams too much as the panacea. I think they will solve lots of problems because they have done so in Node pretty well. But I realize I'm all talk at this point, and so am totally fine with skepticism and "interim" solutions until I can convert that talk into actual results.
# [16:21] * Quits: josemanuel (~josemanue@135.196.221.87.dynamic.jazztel.es) (Quit: Saliendo)
# [16:22] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 252 seconds)
# [16:25] <JakeA> Domenic_: I'm not skeptic about streams at all. My concerns are around saying "Hey devs, this new fetch method is way better than XHR. If you want to get some JSON, just call fetch('yourjson.json').then(… then import some libraries from NPM…"
# [16:26] <annevk> JakeA: I think we should offer things like fetchJSON if we want to compete with libraries
# [16:26] <Domenic_> Why do you want to compete with libraries?
# [16:27] <annevk> Domenic_: less to reason about what is going amiss
# [16:27] <zewt> developers should never need libraries for common things (like "get some JSON")
# [16:27] <annevk> Domenic_: I actually wanted to ask you if you're still thinking of developing JSIDL or IDL or some such
# [16:28] <annevk> Domenic_: as IDL not being maintained is a pain and "just describe it in prose" is massive ugh
# [16:28] <JakeA> annevk: branching at that point seems weird to me, response processing feels separate to making the request
# [16:29] <JakeA> It's less about competing with libraries & more about making the common stuff easier. We're not doing this with SW, because we don't know what the common things are, but we do know people like to fetch json
# [16:29] * Joins: tav (~tav`@host109-154-1-226.range109-154.btcentralplus.com)
# [16:29] <annevk> JakeA: XMLHttpRequest and many libraries do the same though
# [16:30] <JakeA> annevk: I thought you saw XHR as legacy? (I thought you said that when I asked for .send to return a promise)
# [16:30] <JakeA> So the new thing, fetch() shouldn't regress on the old thing in terms of ease-of-use
# [16:31] <jgraham> JakeA++
# [16:31] <annevk> JakeA: yes, however, I don't think overloading the new thing for many different scenarios is the best solution
# [16:32] <annevk> JakeA: if you look at libraries they offer different fetch methods for the common cases
# [16:32] <jgraham> It's not clear to me that there are many different scenarios
# [16:32] <Domenic_> not regressing is a pretty good line to draw
# [16:32] <annevk> jgraham: euh
# [16:32] <jgraham> annevk: Depends which libraries.
# [16:33] <JakeA> annevk: The libraries also fail on 404
# [16:35] <Domenic_> that's an interesting usability question
# [16:35] <annevk> JakeA: ugh
# [16:35] <JakeA> (btw, I don't think fetch() should fail on 404)
# [16:35] <Domenic_> should it fail on 500?
# [16:36] <annevk> JakeA: to go back a few steps; there was a case made when .responseType was introduced, that it was supposed to be settled before the response body came streaming in
# [16:36] <Domenic_> people will have to install something from npm to get fail on 404... ;)
# [16:36] <annevk> JakeA: to allow for UA optimizations
# [16:36] <annevk> JakeA: is that no longer needed?
# [16:36] <Domenic_> ^ key question
# [16:36] <JakeA> Domenic_: if (r.status != 200) throw Error("Nah")
# [16:37] <annevk> Domenic_: it fails on "network error", see Fetch
# [16:37] <annevk> Domenic_: anything else is a successful fetch, but might be failure on the protocol level
# [16:37] <Domenic_> i was being kind of silly. let's talk about the UA optimizations. that's more interesting.
# [16:38] <Domenic_> IN THEORY the UA shouldn't be able to optimize any better than giving the raw data to JS and letting JS optimzie
# [16:38] <annevk> I think it mostly came down to being able to decide what kind of object was going to be used as output before the output arrived
# [16:38] <JakeA> annevk: I'm unaware of the optimisation thing. I'd assumed it was because .response would change type as new formats were added, and that would be baaaad
# [16:38] <Domenic_> I feel that if the UA can optimize better then either (a) it's a matter of raw language primitives that JS is lacking; or (b) the API is not good enough.
# [16:38] <Domenic_> (i.e. the API does not expose enough of the lower-level things JS code needs to be able to do things fast.)
# [16:39] <Domenic_> (a) is worrying but i imagine maybe you can't get any faster than blitting response data into an ArrayBuffer backing store?
# [16:40] <annevk> JakeA: well, say if you do to(x)
# [16:41] <annevk> JakeA: first I do to("json") and then I do to("text") on the same response, that would not allow for said optimizations
# [16:41] <JakeA> annevk: yeah, I'm seeing issues with the enum thing. Although to('unknown type') could reject
# [16:41] * Quits: Ms2ger (~Ms2ger@nata241.ugent.be) (Quit: bbl)
# [16:41] <JakeA> annevk: Oh I see, true
# [16:42] <annevk> The optimization being that you directly parse into JSON upon getting the bits and lose the original data
# [16:42] <JakeA> annevk: I'm absolutely knowledgeless about the optimisation history of responseType
# [16:42] <Domenic_> but. is parsing json from a C++/Rust buffer faster than parsing it in JS from an ArrayBuffer?
# [16:42] <Domenic_> Seems probable :-/
# [16:42] <annevk> JakeA: we designed responseType, because responseXML, responseText, et al was such a mess
# [16:43] <annevk> JakeA: and only allowed for lazy optimization, and you'd still have to keep enough data around
# [16:43] <annevk> Domenic_: JSON.parse() exists
# [16:44] <Domenic_> annevk: I think that's at a whole different level than a byte-by-byte parser...
# [16:44] <JakeA> annevk: Would need to define if to ends or tees the stream
# [16:44] <JakeA> if `to`
# [16:44] <annevk> JakeA: we could do that to() only works the first time you invoke it
# [16:45] <annevk> JakeA: which kinda allows for most of the desired optimizations
# [16:45] <Domenic_> this seems good
# [16:45] * Parts: ato (sid16069@gateway/web/irccloud.com/x-zmeobvohdfqhxyoo)
# [16:45] <annevk> JakeA: it's not very promise-y maybe
# [16:45] <Domenic_> it's stream-ey though
# [16:45] <annevk> promis-ey?
# [16:45] <annevk> hmm
# [16:45] <Domenic_> if you desugar that to streams the most natural way it would indeed consume the stream
# [16:45] <JakeA> Well, it'd be streamy the other way too, it'd be teeing it right?
# [16:46] <JakeA> (am I using the right terminology?)
# [16:46] <Domenic_> yeah it would be, and yeah you are
# [16:46] <Domenic_> but introducing a tee is an extra step
# [16:46] <annevk> JakeA: we could further say that if you invoke .to .body is set to null
# [16:46] <Domenic_> no
# [16:46] <annevk> that might not mean much
# [16:46] <JakeA> annevk: Nah, it's just an exhausted stream
# [16:46] <Domenic_> .body will be an in-the-process-of-being-read stream
# [16:46] <JakeA> or that
# [16:46] <Domenic_> it will be exhausted when the promise fulfills
# [16:47] <annevk> what if you read from .body and the invoke .to?
# [16:47] <JakeA> to would reject
# [16:47] <Domenic_> no
# [16:47] <annevk> or invoke .to and read from body?
# [16:47] <Domenic_> it would give you the JSON representation of the rest of the body
# [16:47] <Domenic_> which would probably be a SyntaxError
# [16:47] <JakeA> oh I see
# [16:47] <Domenic_> if you invoke .to and .read() from the body they're going to interfere with each other pretty badly
# [16:47] <JakeA> Is there a way to tell if you're getting the first bytes of a stream?
# [16:47] <Domenic_> but think of this in terms of desugaring
# [16:48] <JakeA> like a current position, or something
# [16:48] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [16:48] <JakeA> because to() could throw if that isn't zero
# [16:48] <annevk> Domenic_: normally we defend somewhat against such errors
# [16:48] <Domenic_> annevk: OK, as long as it's thought of in terms of defense, that makes sense to me.
# [16:48] <JakeA> (by throw I mean reject)
# [16:49] <Domenic_> JakeA: not in the base stream interface (since bytes are not necessarily a concept at that level). But byte streams could easily add such a property.
# [16:49] <annevk> Domenic_: if someone has a use case we could allow it I suppose
# [16:49] <Domenic_> annevk: I feel like .read() + .to() might have a use case, but the reverse I can't think of one.
# [16:49] <annevk> Domenic_: so the only thing that remains then is how to pass additional info along with a stream
# [16:49] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
# [16:50] <annevk> Domenic_: so you have bytes + encoding for instance which a TransformStream can use if needed
# [16:50] <Domenic_> annevk: yeah, I am thinking on that. will open an issue.
# [16:50] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [16:50] * Quits: Ducki (~Ducki@137.116.197.171) (Remote host closed the connection)
# [16:50] <Domenic_> the model right now is that the destination doesn't know about what's being piped to it. the pipe just writes into it like anyone else
# [16:51] <Domenic_> but this is a clear use case motivating the ability to either tell the destination metadata first, or have the destination query the source
# [16:52] <Domenic_> in node this is handled fairly jankily. source does dest.emit('pipe', source) when piping begins.
# [16:53] <annevk> great
# [16:53] <annevk> I feel like we made some progress on this API
# [16:54] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [16:56] <JakeA> People who leave writing talks late: I do not know how you survive
# [17:03] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [17:04] <Domenic_> not all of us have fancy explosions in our talks jake ;)
# [17:05] <JakeA> I'm using that joke again. I leaned how to do repeats at the BBC
# [17:05] <annevk> I wonder if we can turn JakeA into some kind of media element
# [17:06] <annevk> Play, pause, repeat
# [17:06] <JakeA> As long as I inherit from stream, I get exhausted a lot
# [17:07] <JakeA> especially after a small amount of exercise
# [17:08] <annevk> pub.pipe(jake).pipe(bed).pipe(talk).repeat()
# [17:08] <JakeA> haha
# [17:08] * Quits: hasather (~hasather@guest.schibsted.no) (Remote host closed the connection)
# [17:08] <annevk> (Obvious disclaimer: I have no idea what I'm doing)
# [17:09] * Quits: annevk (~annevk@5ED376C5.cm-7-4b.dynamic.ziggo.nl) (Remote host closed the connection)
# [17:09] * Joins: hasather (~hasather@guest.schibsted.no)
# [17:09] <JakeA> I need a t-shirt with that. Or "cheerfully incompetent"
# [17:09] * Joins: annevk (~annevk@5ED376C5.cm-7-4b.dynamic.ziggo.nl)
# [17:10] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 255 seconds)
# [17:11] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 264 seconds)
# [17:11] <jgraham> TypeError: sessionStorage is null
# [17:11] <jgraham> WTF?
# [17:11] <JakeA> that in "private browsing"?
# [17:11] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
# [17:11] <jgraham> No
# [17:12] <jgraham> http://w3c-test.org/websockets/unload-a-document/001.html
# [17:12] <jgraham> In gecko
# [17:13] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 255 seconds)
# [17:13] * Quits: annevk (~annevk@5ED376C5.cm-7-4b.dynamic.ziggo.nl) (Ping timeout: 240 seconds)
# [17:14] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [17:16] <Domenic_> wow the new html spec buttons look like shit at 2560x1440. they looked great at 1600x900 on my work computer.
# [17:17] <jgraham> They look like shit at 1600x900 on my computer
# [17:17] <jgraham> So much for device independence!
# [17:22] * Joins: BigBangUDR (~Thunderbi@101.59.83.4)
# [17:23] * Joins: mpt (~mpt@nat/canonical/x-zknhwzlinfuruhzu)
# [17:23] * Quits: mpt (~mpt@nat/canonical/x-zknhwzlinfuruhzu) (Changing host)
# [17:23] * Joins: mpt (~mpt@canonical/mpt)
# [17:32] * Joins: saba (~foo@unaffiliated/saba)
# [17:36] * Quits: Gege (gege@future.deferred.io) (*.net *.split)
# [17:46] * Joins: Gege (gege@future.deferred.io)
# [17:50] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [17:51] * Joins: ehsan (~ehsan@66.207.208.102)
# [17:52] * Joins: jeffreyatw (~jeffreyat@173.247.197.10)
# [17:55] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 276 seconds)
# [17:58] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
# [17:58] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [17:59] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [18:01] * Quits: roven (~roven@78-20-24-80.access.telenet.be)
# [18:03] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:05] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [18:06] * Joins: josemanuel (~josemanue@135.196.221.87.dynamic.jazztel.es)
# [18:13] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [18:14] * Quits: josemanuel (~josemanue@135.196.221.87.dynamic.jazztel.es) (Quit: Saliendo)
# [18:15] * Joins: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi)
# [18:15] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Quit: Computer has gone to sleep.)
# [18:16] * Joins: lmclister (~lmclister@192.150.10.210)
# [18:18] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [18:19] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [18:19] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [18:19] * Joins: scor (~scor@drupal.org/user/52142/view)
# [18:20] * Joins: KevinMarks (~yaaic@2607:fb90:509:2025:e6dc:6c5:3c7:6bf8)
# [18:20] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [18:21] * Quits: Lachy_ (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [18:23] * Joins: jsbell (jsbell@nat/google/x-cmqsapqzdifivuwx)
# [18:23] * Quits: espadrine (~ttyl@AMontsouris-158-1-57-222.w92-128.abo.wanadoo.fr) (Ping timeout: 265 seconds)
# [18:23] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [18:23] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [18:23] * Joins: scor (~scor@drupal.org/user/52142/view)
# [18:27] * Joins: IZh (~IZh@83.220.238.65)
# [18:27] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [18:27] * Quits: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi) (Quit: Reconnecting…)
# [18:29] * Joins: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi)
# [18:30] * Quits: tj_vantoll (~Adium@2601:4:5380:eba:2502:8095:8d3a:ed7d) (Quit: Leaving.)
# [18:32] * Joins: yoav (~yoav@212.183.128.157)
# [18:34] * Joins: lubuntu (~chatzilla@37.239.197.79)
# [18:34] * lubuntu is now known as Guest58938
# [18:36] * Joins: encryptd_fractal (~encryptd_@ip-64-134-49-220.public.wayport.net)
# [18:38] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [18:38] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
# [18:46] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [18:49] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
# [18:49] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Client Quit)
# [18:49] * Quits: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi) (Ping timeout: 264 seconds)
# [18:50] * Joins: ambv (~ambv@206.108.217.134)
# [18:51] * Joins: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi)
# [18:51] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [18:53] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [18:54] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [18:55] * Joins: encrypt__ (~encryptd_@12.148.211.210)
# [18:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
# [18:57] * Joins: nielsle (~nielsle@3239078-cl69.boa.fiberby.dk)
# [18:58] * Quits: encryptd_fractal (~encryptd_@ip-64-134-49-220.public.wayport.net) (Ping timeout: 240 seconds)
# [19:02] * Quits: webben (~benjamin@198.61.227.102) (Quit: WeeChat 0.4.4-dev)
# [19:03] * Joins: webben (~benjamin@198.61.227.102)
# [19:04] * Quits: encrypt__ (~encryptd_@12.148.211.210) (Remote host closed the connection)
# [19:04] * Krinkle|detached is now known as Krinkle
# [19:07] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [19:10] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:14] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 252 seconds)
# [19:14] * Joins: weinig (~weinig@17.114.216.47)
# [19:18] * Quits: IZh (~IZh@83.220.238.65) (Read error: Connection reset by peer)
# [19:18] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [19:22] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:23] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 252 seconds)
# [19:24] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
# [19:24] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:25] * Quits: smaug____ (~chatzilla@37-136-213-48.nat.bb.dnainternet.fi) (Ping timeout: 252 seconds)
# [19:25] * Krinkle is now known as Krinkle|detached
# [19:28] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 252 seconds)
# [19:30] <Hixie> mathiasbynens: the fix was to fix the link to point to the right url :-)
# [19:31] * Quits: weinig (~weinig@17.114.216.47) (Quit: weinig)
# [19:32] <Hixie> Domenic_: send me a screenshot showing the "looks like shit"? (i made them all smaller, maybe that's the difference?)
# [19:32] <Hixie> jgraham: if you have a better idea, let me know! i'm scraping the bottom of the barrel for ideas for making the top of the spec more approachable
# [19:33] <Domenic_> Hixie: it's the way they spread wayyy across the window instead of being a 3x3 grid
# [19:33] <Hixie> yeah that's intentional
# [19:33] * Quits: yoav (~yoav@212.183.128.157) (Quit: Ex-Chat)
# [19:33] <Hixie> the 3x3 grid was making weird optical artefacts and taking way too much room
# [19:36] <jgraham> Hixie: It's hard to imagine how it could look worse than http://i.imgur.com/NkwmZz3.png
# [19:36] <jgraham> Which is the single page spec on my computer
# [19:36] <jgraham> (after a bit of scrolling and hovering)
# [19:36] <Hixie> well that's just a bug
# [19:37] <jgraham> No
# [19:37] <jgraham> It's a bug
# [19:37] <Hixie> i mean it's a bug with the browser, not the page
# [19:37] <jgraham> (that we can easilly avoid by not having the gradient)
# [19:37] <jgraham> and it's bad design of the boxes
# [19:37] <jgraham> (the overflowing text)
# [19:37] <Hixie> ooh, the overflowing text is interesting
# [19:38] <Hixie> i guess you don't have Helvetica Neue
# [19:38] <Hixie> what's a good font on your system that's sans-serif and narrow?
# [19:38] <jgraham> And bad design in general (the use of underline at least, possibly the choice of colours, the drop shadow)
# [19:39] <jgraham> (I am not a designer, so that might not be a useful critique, but those elements seem bad to me)
# [19:40] <jgraham> I have no idea. Surely the boxes should make sure they are wide enough for the contained text
# [19:41] <Hixie> obviously opinions differ on whether the general approach is ugly, but since i'm out of other ideas, the only way i can make progress on that is if someone gives a better idea
# [19:42] <Hixie> the boxes are fixed-width so that they line up in a grid
# [19:42] <Hixie> CSS doesn't to my knowledge give me a way to set all of them to the max of their needed widths
# [19:42] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
# [19:42] <Hixie> though that certainly would be nice
# [19:42] <jgraham> Well then I guess you need a script
# [19:43] <Hixie> (note that the general style here is very similar to what whatwg.org has had for years)
# [19:43] <jgraham> But I think I have given concrete suggestions (remove the gradient, the drop shadow, and the underline)
# [19:43] <Hixie> the gradient is cool, the drop shadow is cool, and the underline is needed to show it's a link :-P
# [19:43] * Quits: Guest58938 (~chatzilla@37.239.197.79) (Read error: Operation timed out)
# [19:43] <jgraham> no, no, no
# [19:44] <Hixie> i mean, this is all aethetics, so it's hard to really argue one way or the other
# [19:44] <Hixie> i actually prefer the gradient that firefox does on the single-page spec
# [19:44] <Hixie> just four bands
# [19:44] <Hixie> might switch to that intentionally
# [19:47] <zewt> Hixie: google's search results suddenly stopped underlining the main link ... drives me crazy
# [19:47] <Hixie> agreed
# [19:47] <zewt> hard to read
# [19:48] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 264 seconds)
# [19:49] * Joins: IZh (~IZh@0897578511.static.corbina.ru)
# [19:52] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [19:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [19:57] * Joins: ianloic (sid372@gateway/web/irccloud.com/x-fsslwzhcynapspvv)
# [19:59] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [19:59] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [20:01] <Hixie> man, gradients in blink are all kinds of buggy
# [20:03] <jsbell> Has anyone made (spec, implementation) headway on "replace DOMError with DOMException" ?
# [20:05] * Joins: charl_ (~charl@2a01:4f8:d13:5380:0:c0ff:ee:c0de)
# [20:11] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [20:12] * Krinkle|detached is now known as Krinkle
# [20:13] * Krinkle is now known as Krinkle|detached
# [20:15] * Joins: smaug____ (~chatzilla@cs78246079.pp.htv.fi)
# [20:18] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net) (Remote host closed the connection)
# [20:18] * Joins: llkats (~llkats@h-64-236-138-3.aoltw.net)
# [20:20] * Joins: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be)
# [20:20] * Quits: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
# [20:21] * Joins: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
# [20:29] <smaug____> what has happened to the html spec
# [20:30] <smaug____> uh, dom spec has the same odd background
# [20:30] <smaug____> green text with dark gray background isn't too easy to read
# [20:30] <Hixie> i'm playing with the spec style sheet. i'm not finding something i like, though. so if you have any ideas, do let me know :-)
# [20:31] <Hixie> it shouldn't be a dark grat background
# [20:31] <Hixie> can you send me a screenshot?
# [20:31] <Hixie> gray
# [20:31] <smaug____> not too dark
# [20:31] <Hixie> (if you're using chrome, chrome has all kinds of bugs with this)
# [20:32] <smaug____> oh, it looks totally different in chrome
# [20:32] <smaug____> are you perhaps using some old blink/webkit only gradient syntax?
# [20:32] <Hixie> no
# [20:32] <Hixie> firefox renders it right
# [20:32] <Hixie> chrome gets it all wrong
# [20:33] <smaug____> anyhow, what is wrong with the old background?
# [20:33] <Hixie> nothing, particularly.
# [20:33] <smaug____> or are you just making the test case harder to load in browsers
# [20:33] <Hixie> just seeing if i can find something better.
# [20:33] <smaug____> s/harder/slower/
# [20:33] <smaug____> :)
# [20:33] <KevinMarks_> did the spec just turn into an acid test?
# [20:33] <Hixie> the initial reason for playing with the background was that i was trying to find a way to remove the weird artefacts between the buttons on the html spec
# [20:34] <smaug____> KevinMarks_: it has never been an acid test, but something more useful
# [20:34] <Hixie> but those are gone by just making the buttons smaller, now
# [20:34] * Hixie goes back to the smooth gradient
# [20:34] <smaug____> in chrome I see a smooth gradient
# [20:34] <smaug____> but oddly slow scrolling speed
# [20:35] <Hixie> chrome's a disaster
# [20:35] <Hixie> trying zooming in and out
# [20:35] <Hixie> or selecting text
# [20:36] <Hixie> and the bands are the wrong widths
# [20:36] <Hixie> and sometiems it's at the wrong angle
# [20:36] <Hixie> and it repaints badly
# [20:37] <smaug____> Hixie: so I was going to look at the spec and what it says about img elements and img loading in case the element is from a document which isn't in any current/active browsing context
# [20:37] <smaug____> looks like blink just doesn't let one to load a new image using such img element
# [20:37] <smaug____> gecko doesn't have such limitation
# [20:37] <Hixie> this is an img that's in a browsing context but not active?
# [20:38] <smaug____> right
# [20:38] <smaug____> say, img element from an iframe
# [20:38] <smaug____> and then iframe is removed from its parent doc
# [20:38] <Hixie> the iframe in that case loses its browsing context, no?
# [20:39] <smaug____> or a new page is loaded to the iframe or so
# [20:39] <smaug____> Hixie: right
# [20:39] <Hixie> "When an iframe element is removed from a document, the user agent must discard the nested browsing context."
# [20:39] <Hixie> so there the img wouldn't have a browsing context at all
# [20:39] <Hixie> not just not an active document in a browsing context
# [20:40] <smaug____> well, what about the case when a new page is loaded to the iframe
# [20:41] <Hixie> looks like the spec is unclear on all this
# [20:41] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
# [20:42] <Hixie> if there's no browsing context, "fetch" doesn't do anything. if there's a browsing context and it's not active, "fetch" queues up the tasks but they don't do anything until the document is active.
# [20:42] <Hixie> so the img would suddenly update when you navigate back to that page in the session history, in theory
# [20:42] <Hixie> which seems unlikely to match browsers
# [20:42] <Hixie> but who knows
# [20:42] <Hixie> i haven't tested it
# [20:43] <smaug____> blink say something like "request cancelled" or some such in the console
# [20:44] <smaug____> hmm, but ok, queuing makes sense, possibly
# [20:50] <Hixie> i'm soon going to be rewriting the img loading section, so if this needs to be adjusted, now's a good time to do it
# [20:52] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [20:53] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [20:54] * Quits: BigBangUDR (~Thunderbi@101.59.83.4) (Ping timeout: 252 seconds)
# [20:55] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [20:57] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
# [20:58] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
# [20:59] <jgraham> Hixie: In the interests of being constructive, I think http://imgur.com/zhxdXcC is an improvement
# [20:59] <jgraham> Although that brown is still particularly ugly
# [21:02] * Joins: fishd__ (~darin@216.239.45.66)
# [21:03] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:06] * Joins: slopjong (~slopjong@linda.rhrk.uni-kl.de)
# [21:06] * Quits: fishd_ (~darin@216.239.45.83) (Ping timeout: 240 seconds)
# [21:09] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 255 seconds)
# [21:09] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [21:14] * Joins: rniwa (~rniwa@17.202.43.222)
# [21:18] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:20] <KevinMarks_> you could just make it a 2048 clone and use their colours
# [21:24] * Quits: saba (~foo@unaffiliated/saba) (Quit: leaving)
# [21:26] <Hixie> jgraham: that's too big, though. takes up so much room that you can hardly see any of the ToC on anything but a big screen.
# [21:26] <Hixie> jgraham: (it's more or less what we had yesterday)
# [21:26] <Hixie> jgraham: (also i can't tell that those are links)
# [21:27] <Hixie> jgraham: (and it suffers from the intersection optical illusion problem that i was trying to get rid of with the gradient)
# [21:29] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [21:29] <Hixie> jgraham: (also, the green isn't whatwg green and the other colours are a bit bright... we were trying to make them darker yesterday because people complained about it being too in your face)
# [21:35] <jgraham> Hixie: Being able to see the ToC isn't very useful anyway. The brightness is intentional because your colours are really ugly and muddy. There's a reason that no one makes UIs in dark colours. Also I think it is quite easy to guess that they are links. I mean at least as easy as it is to guess that the android/iOS/windows UI elements for launching applications are clickable
# [21:36] <jgraham> the green is the same hue/saturation but 50% brighter
# [21:36] <Hixie> lots of UIs are dark
# [21:37] <jgraham> Pretty sure the lat time I saw that teal colour in a UI was a non-default windows 3.1 theme
# [21:37] <Hixie> the launcher on Android uses icons, with a pictures and a label, which has a long history of being clickable. Here we're making things look just like labels.
# [21:37] <Hixie> i don't think there's a parallel.
# [21:38] <Hixie> my mail client, my irc client, and my editor all have black backgrounds. Can't get much darker than that.
# [21:39] <Hixie> the buttons at the top of http://www.apple.com/ are dark
# [21:39] <Hixie> (and don't look clickable, but that's another story)
# [21:39] <jgraham> OK, let me rephrase
# [21:39] <jgraham> Those colours are ugly
# [21:39] <jgraham> Brighter colours are less ugly
# [21:40] <Hixie> yesterday jcgregorio argued the opposite.
# [21:40] <jgraham> Your boxes don't look clickable
# [21:40] <Hixie> no, the boxes don't. but the text is underlined, so the text is obviously a link.
# [21:40] <IZh> Hi all. Is it possible to make SVG elements to have relative coordinates (to previous element). I want to implement collapsible tree control (where you can expand items by clicking on [+]). I consider html+canvas and svg. In html it's not easy to draw. But in svg it's hard to make simething to collapse like in html (display: none). In svg it's possible to make things like display:hidden.
# [21:40] <jgraham> No
# [21:40] <jgraham> There is nothing about your text that says link to me
# [21:40] <Hixie> ok
# [21:41] <Hixie> if underline doesn't mean "link" to you, i don't know what to say
# [21:41] <jgraham> Huge amounts of the web doesn't use underline for links anymore
# [21:41] <Hixie> anyway, i'm not a fan of this whole box approach
# [21:41] <Hixie> huge amounts of the web suck :-)
# [21:41] <IZh> +1
# [21:41] <jgraham> Because it's ugly and makes the text hard to read
# [21:42] <jgraham> Despite this people still manage to figure out which things are links
# [21:44] <Hixie> anyway. as i said before, what i'd really like is some better solution that gets away from this whole block paradigm
# [21:44] * Joins: ap (~ap@17.202.44.214)
# [21:45] <jgraham> Sure
# [21:45] <Hixie> some sites use a similar grid approach but with icons, but i'd rather not have to link in a bunch of images
# [21:46] <Hixie> (not to mention having to get the artwork)
# [21:46] <jgraham> In the meantime, can we have something that isn't going to actively make me add a user stylesheet if it doesn't change?
# [21:46] <Hixie> give me a break, the current style isn't that bad
# [21:46] <Hixie> it's way better than what we had before
# [21:47] <Hixie> and it's not like you're gonna spend any time actually looking at the top of the spec
# [21:47] <jgraham> I don't know what to say. I actually am going to turn it off if it stays like this. That's just a fact
# [21:47] <Hixie> ok
# [21:48] <Hixie> i mean, these links aren't useful to either you or me anyway
# [21:48] <Hixie> so making them display:none would be an improvement for both of us
# [21:49] <Hixie> but what i'm going for is trying to get new readers to see that there's useful things they could look at
# [21:49] * doctrv is now known as emerson
# [21:50] <jgraham> Sure, I appreciate the idea
# [21:51] * emerson is now known as doctrv
# [21:52] <KevinMarks_> it could be more annoying, you could steal http://leaverou.github.io/animatable/
# [21:52] * Joins: gavinc (~gavin@50.0.77.3)
# [21:53] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [21:55] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [21:58] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [21:59] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
# [22:03] * Joins: fishd_ (~darin@216.239.45.83)
# [22:03] <Hixie> jgraham: i played with it some more
# [22:06] * Quits: fishd__ (~darin@216.239.45.66) (Ping timeout: 240 seconds)
# [22:07] * Joins: weinig (~weinig@17.114.216.47)
# [22:07] <MikeSmith> wondering what zcorpan meant by the "xml" restriction for <embed>, and "it only gives a warning for foo:bar foo,bar etc, rather than an error"
# [22:08] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [22:08] <MikeSmith> I guess he meant "Any namespace-less attribute other than name, align, hspace, and vspace may be specified on the embed element, so long as its name is XML-compatible and contains no uppercase ASCII letters"
# [22:08] <IZh> How to make part of SVG to collapse?
# [22:08] <MikeSmith> and the warning in that case comes from the parser
# [22:09] <Hixie> MikeSmith: "Attribute names are said to be XML-compatible if they match the Name production defined in XML, they contain no U+003A COLON characters (:), and their first three characters are not an ASCII case-insensitive match for the string "xml"."
# [22:09] <Hixie> IZh: it seems there's not many people here who know svg well enough to help you :-(
# [22:12] * Joins: tantek (~tantek@172.56.38.34)
# [22:13] <IZh> I'm not sure that I need SVG. I want to visualize processes CPU consumption. For each process I have a plot that shows CPU utilization over the time. And for each process I know its children. So I want to show a process tree with the ability to collapse unneded subtree.
# [22:13] <MikeSmith> Hixie: yeah so as far as the validator goes, the HTML parser already checks for XML-compatibility of attribute names now, and emits a warning if they're not XML-compatible. But in the case of embed, I guess it needs to be an error to conform to the spec. I guess we could have the parser check to see what element it has open at the point when it emits the current warning message, and if it's embed, change to emitting it as an error instead
# [22:13] <IZh> HTML works better for collapsion. But SVG works better for plot drawing...
# [22:14] <Hixie> MikeSmith: well note that the i expect zcorpan to file a bug (if he hasn't already) asking for this to change
# [22:14] <Hixie> MikeSmith: since apparently the very stable XML 1.0, fifth edition, has errata that removes this reservation.
# [22:14] <Hixie> or something.
# [22:14] <Hixie> but don't worry! TR/ drafts are STABLE.
# [22:15] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [22:16] <MikeSmith> hah
# [22:16] <MikeSmith> yeah
# [22:17] * Quits: IZh (~IZh@0897578511.static.corbina.ru) (Remote host closed the connection)
# [22:17] * Joins: IZh (~IZh@0897578511.static.corbina.ru)
# [22:18] * Quits: jeremyj (~jeremyj@17.202.44.231) (Client Quit)
# [22:20] <KevinMarks_> IZh you could look at d3.js - that makes interactive SVG easier
# [22:21] <KevinMarks_> IZh: or put multiple SVG charts inline in HTML and use the HTML to collapse them
# [22:22] * Quits: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net) (Quit: Textual IRC Client: www.textualapp.com)
# [22:23] * Joins: morrita_ (uid16889@gateway/web/irccloud.com/x-dwepxvywgebocbxy)
# [22:23] <IZh> KevinMarks_: I thought about it. May be lots of svgs is better (although it will be hundreds or thousand). But it was strange to me that there are no more easy ways.
# [22:24] <KevinMarks_> if they're individually linkable, that may be more generally useful - then you can share one weird one
# [22:24] <TabAtkins> IZh: By "collapse", what do you mean? Hide them?
# [22:24] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [22:24] <IZh> Not only hide, but move all elements below it up.
# [22:25] <IZh> Like in html when you remove a paragraph, all subsequent paragraphs will be shifted up.
# [22:25] <TabAtkins> Oh, if you're doing SVG, you have to handle all layout yourslef.
# [22:26] <TabAtkins> SVG is like using HTML with "* { position: absolute !important; }" applied.
# [22:26] <TabAtkins> It's for drawing, not for documents.
# [22:26] <IZh> But in svg I didn' find a way to provide relative coordinates. It seems, they are all absolute.
# [22:26] * Quits: weinig (~weinig@17.114.216.47) (Quit: weinig)
# [22:26] <TabAtkins> Correct.
# [22:27] <IZh> So hiding the element doesn't move up next elements.
# [22:27] <TabAtkins> Yes, that's what I'm saying.
# [22:28] <IZh> But why they don't have relative coords? :-)
# [22:28] <IZh> Of course, all could be done with the help of js
# [22:28] <IZh> But I first tried to find a way without it.
# [22:29] * Joins: benv (~benv@208.64.184.50)
# [22:30] <TabAtkins> Because it's a drawing language, not a document language. (Also, because the WG has traditionally been dominated by tool vendors, who don't care about hand-authoring, rather than people representing authors.)
# [22:30] <TabAtkins> Either use HTML for your document structure, using SVG for the actual drawings when you need it, or do the whole thing in SVG with a bunch of JS to handle layout.
# [22:31] <TabAtkins> I recommend the former.
# [22:34] <IZh> I tried to avoid thousand svgs in one document. But it seems, I have no choice. :-)
# [22:35] <TabAtkins> There's no difference between 1k <svg> diagrams and a giant <svg> containing 1k diagrams.
# [22:35] * Quits: foxtrotwhiskey (~foxtrotwh@192-63-2457.unisys.com) (Ping timeout: 255 seconds)
# [22:36] <KevinMarks_> well, a lot of HTTP setup and teardowns?
# [22:36] <KevinMarks_> or you mean inline SVG?
# [22:36] <IZh> Inline
# [22:36] <TabAtkins> KevinMarks_: Inline SVG.
# [22:36] <KevinMarks_> ah, OK.
# [22:36] <TabAtkins> Yeah, 1k external resources is clearly worse, but there's no reason to do that.
# [22:37] * Quits: jernoble (~jernoble@17.202.46.221) (Quit: Textual IRC Client: www.textualapp.com)
# [22:37] <KevinMarks_> well the reason is creating separate links for each diagram so you can share just one
# [22:37] * Quits: tantek (~tantek@172.56.38.34) (Quit: tantek)
# [22:37] * Joins: jernoble (~jernoble@17.202.46.221)
# [22:37] <KevinMarks_> with existing img UA model
# [22:37] <TabAtkins> You can do this too, with an appropriately smart preprocessor.
# [22:38] <KevinMarks_> or img with a data URI for the SVG
# [22:38] <TabAtkins> And just make them linkable with an ID. Why link to them separately?
# [22:38] <TabAtkins> Like, http://dev.w3.org/csswg/css-syntax/#token-diagrams is just fine.
# [22:40] * Joins: jensnockert (~jensnocke@212.209.1.74)
# [22:41] <IZh> http://www.bootchart.org/images/bootchart.png
# [22:41] <KevinMarks_> as long as you don't want to copy one image
# [22:41] <IZh> I want something like this.
# [22:41] <IZh> But I want to collapse/expand a subtree of processes
# [22:42] <IZh> Like in a tree-like folder view.
# [22:42] * Quits: smaug____ (~chatzilla@cs78246079.pp.htv.fi) (Ping timeout: 252 seconds)
# [22:43] <KevinMarks_> d3 is good at that kind of thing https://github.com/mbostock/d3/wiki/Gallery
# [22:46] <IZh> d3 is a library. But what will be in the DOM? Lots of <svg>? Is seems there is no other way.
# [22:46] <IZh> Or to regenerate big image frow the data on the fly by d3.js.
# [22:46] <IZh> From
# [22:46] <KevinMarks_> yes, lots of svg in the dom
# [22:46] <Hixie> does validator.nu have a "check the referer" option?
# [22:46] <Hixie> or did that get killed along with badges
# [22:47] <TabAtkins> IZh: I have no clue why you think "lots of <svg>" is a bad thing. It's not. Just let it happen.
# [22:47] <MikeSmith> Hixie: does not have that option
# [22:48] <KevinMarks_> SVG is great, shame more sites don't support it as an image type
# [22:49] <IZh> TabAtkins: I thought it will be more easy for the browser to handle one big document than to handle 1000 inline documents.
# [22:50] <Hixie> MikeSmith: k
# [22:50] <Hixie> MikeSmith: is there a bookmarklet for validator.nu i could use?
# [22:51] * Quits: jensnockert (~jensnocke@212.209.1.74) (Remote host closed the connection)
# [22:52] * Quits: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be) (Ping timeout: 240 seconds)
# [22:52] <MikeSmith> Hixie: there probably is but I don't know of any specific one. there are some browser plugins I know of
# [22:52] <Hixie> k
# [22:53] * Quits: benv (~benv@208.64.184.50) (Quit: Computer has gone to sleep.)
# [22:54] * Joins: benv (~benv@208.64.184.50)
# [22:54] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [22:59] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [23:02] * Joins: tantek (~tantek@172.56.38.34)
# [23:02] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [23:03] * Joins: benv_ (~benv@208.64.184.50)
# [23:04] * Quits: tantek (~tantek@172.56.38.34) (Client Quit)
# [23:05] * Quits: TallTed (~Thud@63.119.36.36)
# [23:06] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 240 seconds)
# [23:07] * Quits: benv (~benv@208.64.184.50) (Ping timeout: 264 seconds)
# [23:09] * Joins: weinig (~weinig@17.114.216.47)
# [23:17] * Quits: benv_ (~benv@208.64.184.50) (Quit: Computer has gone to sleep.)
# [23:19] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
# [23:20] * Quits: IZh (~IZh@0897578511.static.corbina.ru) (Remote host closed the connection)
# [23:22] * Joins: jensnockert (~jensnocke@212.209.1.74)
# [23:25] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [23:25] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [23:29] * Quits: lmclister (~lmclister@192.150.10.210)
# [23:30] * Joins: benv (~benv@208.64.184.50)
# [23:32] * Joins: jensnockert_ (~jensnocke@212.16.170.227)
# [23:36] * Quits: jensnockert (~jensnocke@212.209.1.74) (Ping timeout: 252 seconds)
# [23:40] * Quits: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [23:40] * Joins: bholley (~bholley@c-50-148-162-19.hsd1.ca.comcast.net)
# [23:57] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# Session Close: Sat Apr 26 00:00:00 2014

The end :)