| 03:48 | <roc> | is he taller than Anne? |
| 03:57 | <TabAtkins> | roc: He... might be. |
| 03:57 | <TabAtkins> | I've met him, and he's significantly taller than me. |
| 04:00 | <MikeSmith> | http://foolip.files.wordpress.com/2013/10/webtech.jpg |
| 04:01 | <MikeSmith> | that's how much taller he is than Erik Dahlstrom or Lars-Erik or others you might know |
| 04:26 | <caitp> | always show respect and gratitude for tall people, you know not how many door frames they've walked into just for the opportunity to speak with you today |
| 06:55 | <MikeSmith> | a developer on github seems to be suggesting I switch to using Jekyll for validator docs I'm publishing at http://validator.github.io But it's uncomplicated set of content (two pages) that doesn't change often and my publishing setup is dead-simple already, so I don't know how relying on Jekyll would make things any easier or better |
| 06:56 | <MikeSmith> | context is https://github.com/validator/validator.github.io/issues/7 |
| 06:59 | <karlcow> | MikeSmith: seems a lot of pipes for two pages without apparent benefits. |
| 07:01 | <MikeSmith> | karlcow: yeah but I wondering if I'm missing something |
| 07:03 | <MikeSmith> | the appeal of a lot of these markdown systems seems to be based on a view that authoring in HTML is somehow more trouble, or that it's a barrier to getting contributions from other people (with the assumption being that other people find authoring in HTML to be a lot of trouble) |
| 07:04 | <tantek> | it is not that authoring in HTML is a lot of trouble, but rather that it distracts from authoring. It's noise that interrupts the process of conveying thoughts into text. |
| 07:05 | <MikeSmith> | I'm wondering if I'm being a techno-reactionary by not personally finding HTML authoring to be a big pain point |
| 07:05 | <tantek> | MikeSmith: I both don't find HTML authoring to be a big pain point, and yet I also feel its intrusion on the thought process of writing content. |
| 07:06 | <MikeSmith> | tantek: I personally don't find it an interruption to my thought process much at all. Maybe that's just because I'm used to it. |
| 07:06 | <tantek> | but for the issue at hand, once you've gone to the trouble of writing content in HTML, it's the easiest thing to maintain. instead of a system to convert to HTML. |
| 07:07 | <MikeSmith> | yeah |
| 07:07 | <tantek> | MikeSmith: I author every single one of my notes on my site in HTML in the storage file for it. Every tweet you see from me was written first in HTML on my own site. |
| 07:07 | <tantek> | since 2010-01-01. |
| 07:07 | <MikeSmith> | ok |
| 07:08 | <tantek> | Though I'm "used to it" I do sense where it slows me down. Still. |
| 07:08 | <tantek> | so I have some sympathy for the markdown advocates, despite not using markdown myself. |
| 07:08 | <MikeSmith> | yeah me too, but again, the right tool for the job and all that |
| 07:09 | <MikeSmith> | I mean I wouldn't want to write my e-mail messages in HTML |
| 07:09 | <MikeSmith> | so I can understand the general sentiment |
| 07:09 | <tantek> | I do however do two things which make my authoring much easier than "just" HTML |
| 07:09 | <tantek> | 1. I use white-space pre-wrap |
| 07:09 | MikeSmith | nods |
| 07:10 | <tantek> | 2. I use an auto-linker/embedder |
| 07:10 | <MikeSmith> | dunno what an auto-linker/embedder is |
| 07:10 | <tantek> | (my own open source one, function auto_link() in tantek.com/cassis.js (works in PHP and JS)) |
| 07:10 | MikeSmith | takes a look |
| 07:11 | <tantek> | you give it mixed text with URLs, and it turns the text URLs into <a href> links, and if the URL ends in .jpg .png .gif it embeds it as an <img src>, and if it is video, <video>, or custom Youtube/Vimeo video embeds. all just from URLs. |
| 07:11 | <tantek> | you give it a plain text string, it gives you a string with *some* markup |
| 07:12 | <MikeSmith> | yeah, nice |
| 07:13 | <tantek> | so that saves me considerable time in my notes (which become tweets) |
| 07:13 | <MikeSmith> | sure |
| 07:13 | <tantek> | my articles (blog posts) though are written 100% in HTML. Every paragraph with explicit <p></p> etc. |
| 07:13 | <tantek> | no auto_link use in my blog posts |
| 07:13 | <MikeSmith> | oh |
| 07:13 | <tantek> | so yes they take longer to write, even just to do all the markup by hand |
| 07:14 | <tantek> | but it means I have more precise control over all the markup |
| 07:14 | <MikeSmith> | right |
| 07:14 | <MikeSmith> | that's what it comes down to in the end for me |
| 07:15 | <MikeSmith> | I guess I'd rather have the precise control directly than trying to wrestle with figuring how to to get whatever markdown system to generate that |
| 07:15 | <tantek> | yeah - I agree, I have my own analysis/criticism of markdown documented here: http://tantek.com/w/Markdown |
| 07:15 | <MikeSmith> | there are cases of groups using a common markdown mechanism makes a lot of sense |
| 07:16 | <MikeSmith> | like the Python ReST docs |
| 07:16 | MikeSmith | takes a looks at http://tantek.com/w/Markdown |
| 07:16 | <tantek> | and with that I must go to sleep. Enjoy and talk more in the morning(PDT). |
| 07:17 | <MikeSmith> | cheers |
| 07:17 | <MikeSmith> | nn |
| 09:18 | <tobie> | Saw Hixie mention a URL spec snapshot on webapps@ the other day. Is there something consistent across specs here? Would love to automatically include that data in specref. |
| 09:20 | <Ms2ger> | Don't. |
| 09:20 | <tobie> | Why not? |
| 09:20 | <Ms2ger> | It's not supposed to be referenced |
| 09:21 | <tobie> | I'm genuinely trying to understand what the end goal is, here. |
| 09:22 | <Ms2ger> | Dunno |
| 09:22 | <Ms2ger> | But referencing it definitely isn't |
| 09:22 | <tobie> | so it's better to have W3C clones? |
| 09:23 | <Ms2ger> | No? |
| 09:23 | <foolip> | The W3C wouldn't stop forking specs if WHATWG started publishing stable copies... |
| 09:24 | <tobie> | foolip, really? What makes you so sure? |
| 09:24 | <tobie> | How sustainable would that position be? |
| 09:24 | <tobie> | Afaik, WHATWG is publishing such versions for certain specs. |
| 09:25 | <Ms2ger> | Have you ever interacted with the W3C? |
| 09:26 | <foolip> | tobie: I think they want more of the whole process things as well, partially for the patent policy I'm guessing |
| 09:27 | foolip | scrolls up and sees that self is scary for being tall and removing code :) |
| 09:27 | <foolip> | zcorpan: which bug was that, I couldn't find the context |
| 09:30 | <tobie> | foolip: WHATWG has a patent policy through its W3C CG. |
| 09:31 | <tobie> | Ms2ger: are you really answering me with rhetorical questions? I'd rather you'd just tell me to fuck off. :) |
| 09:38 | <zcorpan> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 |
| 09:41 | <foolip> | tobie: yes, but somehow that doesn't seems to be enough |
| 09:44 | <tobie> | foolip: that's not enough for some. It's certainly enough for others. |
| 09:45 | <tobie> | Anyway, I think marcos is spot on finding this feud unproductive. |
| 09:45 | <jgraham> | Isn't the point that the stable specs are a necessary part of the patent policy? |
| 09:46 | <foolip> | If I were to bet money, I would still bet on the W3C continuing to fork, pretty much regardless of how the specs on whatwg.org are published |
| 09:46 | <jgraham> | You can't just cover "anything that we ever write down", but you can cover "things we wrote down and agreed to put in a stable spec" |
| 09:46 | <foolip> | zcorpan: thanks, that was actually in my inbox but I hadn't gotten to it yet :) |
| 09:48 | <jgraham> | Yeah, so there's definitely a conflict of interests that the W3C has here which means that it won't necessarily stop forking specs just because there is no technical reason to do so |
| 09:50 | <foolip> | tobie: did marcos write a blog post or something? |
| 09:51 | <jgraham> | I love the way irc avoids centralisation |
| 09:51 | <foolip> | a hint of irony? context? |
| 09:53 | <jgraham> | I thought it was irccloud going down (again), but maybe it was just a lot of people on ircclod getting cut of with some other people |
| 14:11 | <erlehmann> | has anyone thought about a size-parameter to <img> for responsive images? |
| 14:11 | <erlehmann> | like, just size in octets? |
| 14:12 | <erlehmann> | because that could work fairly well for progressive images |
| 14:12 | <erlehmann> | otherwise, for everyone who does not use command line tools, it would not be easy to author |
| 14:12 | <erlehmann> | maybe the general fetch declarative parameters could help here |
| 14:18 | <zcorpan> | erlehmann: how do you mean? |
| 14:19 | <erlehmann> | zcorpan jpeg images can contain several scans. something like <img size=12345 src="…"> could only fetch until the first scan. |
| 14:19 | <erlehmann> | progressive jpegs |
| 14:19 | <erlehmann> | but this is too low-level for day-to-day use i think |
| 14:20 | <erlehmann> | and maybe solves the problem at the wrong abstraction level (see client hints) |
| 14:21 | <erlehmann> | i am doing a writeup on the technique |
| 14:26 | <zcorpan> | erlehmann: i think that has been considered. yoav also experimented with a more elaborate image format that supports art direction, but deploying it would take more time than <picture> since it requires changes at several layers |
| 14:26 | <erlehmann> | zcorpan i'll do my writeup regardless ;) |
| 14:27 | <zcorpan> | might still happen in the future though |
| 14:27 | <zcorpan> | sure :-) |
| 14:28 | <erlehmann> | zcorpan for the picture element, a size parameter may make sense also, if you have progressive jpegs. |
| 14:28 | <erlehmann> | then you could have one file that is served which contains all scans |
| 14:40 | <yoav> | erlehmann: I've looked into both using progressive jpegs and a dedicated container format at http://blog.yoav.ws/2012/05/Responsive-image-format and http://blog.yoav.ws/2013/09/Responsive-Image-Container |
| 14:41 | <erlehmann> | yoav great! |
| 14:41 | <yoav> | erlehmann: I think that a size attribute would be a huge maintenance pain though |
| 14:41 | <erlehmann> | yeah |
| 14:41 | <erlehmann> | client hints are probably much better |
| 14:42 | <yoav> | A responsive image format has its advantages (e.g. can download diffs between image qualities), but it's hard to pull off (ecosystems are hard) |
| 15:44 | <cwilso> | tobie: "WHATWG has a patent policy through its W3C CG" is a factually incorrect statement. It would be correct to say "The WHATWG W3C CG has a patent policy." |
| 15:46 | <tobie> | cwilso: how is that difference relevant? |
| 15:46 | <tobie> | cwilso: that's a genuine question. |
| 15:48 | <cwilso> | tobie: The bulk of the work done by the WHATWG is done outside the CG. For example, there are currently 209 people in this chat. No idea how many people are on the whatwg@ list, but suspect it's similar scale. There are only 51 members of the WHATWG W3C CG. |
| 15:49 | <tobie> | Sure. But forking that spec to W3C doesn't magically change that. |
| 15:49 | <cwilso> | tobie: Only those 51 participants *might* be making IP commitments. The work is simply not done inside a structure that supports IP. |
| 15:49 | <cwilso> | tobie: no, forking absolutely does not fix this. |
| 15:51 | <cwilso> | It does *change* it in a subtle way - because any member of the WG to which a spec might be forked then DOES make a commitment (unless they exclude), so there is a bit more coverage, potentially - but that's not a reason to fork, in and of itself. (I do want to be clear that I don't consider that a reason to fork.) |
| 15:51 | <tobie> | Well, especially that could be handled a different way, right? |
| 15:52 | <tobie> | I mean, one could imagine W3C members making such a commitment despite the spec not being published by W3C. |
| 15:52 | <cwilso> | Well, sure. The WHATWG could have an up-front patent policy. As I suggested when I was originally asked to join the WHATWG. |
| 15:53 | <cwilso> | No, the W3C's patent policy is only for specs they produce. And I think you'd find any large-patent-pool-holders unwilling to sign up for a "hey, we're gonna apply your commitment to these other specs we don't own, 'k?" |
| 15:53 | <cwilso> | Or else I have a list of specs to add there. Starting with H.264. :P |
| 15:53 | <tobie> | Not sure. has this been discussed by the AC? |
| 15:54 | <tobie> | (Note this would be for snapshots only, obviously) |
| 15:55 | <cwilso> | The AC isn't much of a discussion pool. But yeah, this very discussion has been had. |
| 15:55 | <cwilso> | And there's your other problem - because snapshots are pretty much anathema to most WHATWGers, because of staleness. |
| 15:55 | <tobie> | most specs are versioned. |
| 15:56 | <jgraham> | I think people are OK with the idea that there could be lawyer-centric snapshots |
| 15:56 | <cwilso> | In fact, some of the W3C "forks" are (as I understand it) are pretty strict snapshots of WHATWG specs; but that can still cause staleness. |
| 15:56 | <cwilso> | this isn't lawyer-centric. |
| 15:57 | <jgraham> | It's also not clear to me how the CG thing matters. The patent policy is only about defending known threats. You decide when joining a WG "are enough of the people that I am scared in relation to this work of also in this WG". It seems like the exact same consideration applies to a CG |
| 15:57 | <jgraham> | It doesn't matter that there are only N people if those are the ones you care about |
| 15:58 | <cwilso> | Any idea this is just for lawyers to fiddle with is simply mistaken. Yes, the lawyers need to be satisfied for IP stuff; but if you say "IP commitments apply to this [stale?] snapshot, but don't look at that, the real spec's over here", you are opening up another opportunity for staleness. |
| 15:58 | <tobie> | IP lawyers are generally freaked out by the CG patent policy, fwiw. |
| 15:58 | <jgraham> | That sounds promising :p |
| 15:59 | <tobie> | They can't control the scope of their contribution as well as with WGs. |
| 15:59 | <cwilso> | jgraham: Your statement is mostly correct - but the goal is "let's get enough of the people I am scared of into this WG, so they make commitments (or are clear about exclusions) and I don't need to be scared of them." |
| 16:00 | <tobie> | So my question here is: why do people go in WGs in the first place? |
| 16:00 | <cwilso> | that's absolutely true, CGs are a bit looser. But they also can't produce RECs directly. They're great as incubators, in my opinion. |
| 16:01 | <cwilso> | Because in the past, that was the only way to really participate in designing solutions. |
| 16:01 | <tobie> | So the only carrot is the technical forum? |
| 16:01 | <cwilso> | And because the more people were there, the less the likelihood you'd be sued for implementing. |
| 16:02 | <tobie> | The latter's still true whether or not there's an attached technical forum, no? |
| 16:02 | <cwilso> | no |
| 16:02 | <tobie> | why not? |
| 16:02 | <cwilso> | Because if there's no carrot, no one participates, and there's no IP contributions. |
| 16:03 | <cwilso> | If, say, Oracle doesn't need to sign up to a WG to participate in the definition of IDB to make sure it's going to work well for them, then they certainly wouldn't want to join just to give away their IP. |
| 16:04 | <cwilso> | note this is a hypothetical example, not a real one. Or maybe it is, I have no idea, but I'm not making any claims. |
| 16:05 | <tobie> | Joining has no IP value for them unless they're actually implementing some of the specs in that group, btw. |
| 16:06 | <cwilso> | not really true. "Actually implementing" implements browser vendors only; there are subtler interactions than that. |
| 16:07 | <cwilso> | s/implements/implies |
| 16:07 | <tobie> | like which ones? |
| 16:08 | <cwilso> | Well, for example, the WG had been on a WebSQL path; that clearly would not have been good for Oracle, since it defines the standard for the web (for better or worse) to be WebSQL. Yes? |
| 16:09 | <tobie> | Indeed. |
| 16:09 | <tobie> | (Not sure yet where you're going with that.) |
| 16:11 | <cwilso> | It would be better for Oracle (and now I'm getting uncomfortable with using a concrete example) for WebSQL to NOT be the standard, and a more open ecosystem that their products could interact with, to be defined as a standard? |
| 16:14 | <tobie> | Sure. |
| 16:14 | <tobie> | Sorry for the making you uncomfortable. Why don't you pick a Microsoft product instead? |
| 16:14 | <tobie> | :P |
| 16:16 | <tobie> | Note DBCo doesn't NEED to be member of said WG to disclose IP. |
| 16:16 | <tobie> | (if that's where you're getting at) |
| 16:52 | <erlehmann> | yoav zcorpan http://news.dieweltistgarnichtso.net/notes/progressive-jpeg-truncate.html |
| 17:01 | <erlehmann> | yoav zcorpan nothing new, right? |
| 17:04 | <cwilso> | tobie: :P |
| 17:05 | <cwilso> | No, they don't need to be member of said WG to disclose IP. But remember the goal - you want more people CONTRIBUTING their IP. Whether intentionally because they're good sharers, or as a side of effect of being in the group. |
| 17:09 | <zcorpan> | erlehmann: right |
| 17:58 | <zcorpan> | what is correct behavior for jsfiddle.net/zzw9wpdq/6/ ? |
| 18:01 | <zcorpan> | TabAtkins: ^ |
| 18:02 | <caitp> | I see the same behaviour from FF31, fwiw |
| 18:06 | <caitp> | oh, it is different behaviour, just not different in the way you describe it |
| 18:06 | <caitp> | .container expands to contain both .inline-block and the image in chrome, while in ff it doesn't |
| 18:25 | <Hixie> | tobie: the snapshots are for lawyers, not for implementors. don't reference them. Referencing stale drafts is a mistake (that the W3C and the IETF keep making) |
| 18:26 | <Hixie> | cwilso: whatwg@ has ~2000 members. |
| 18:26 | <Hixie> | cwilso: any of which are welcome to joing the cg if they want to make a patent commitment, just like they're presumably welcome to join w3c wgs to make patent commitments |
| 18:27 | <Hixie> | given that we haven't made any sort of public announcement to encourage such behaviour, it's actually kinda shocking that 50 people have joiend the cg in the first place |
| 18:27 | <Hixie> | i dunno why anyone would join the cg |
| 18:27 | <Hixie> | i guess i should post on the whatwg blog about the url standard |
| 18:35 | <wanderview> | JakeA: ping |
| 18:36 | <wanderview> | do we expect [[BatchCacheOperations]] to remain in the cache spec once its updated? |
| 18:36 | <wanderview> | is that a hold over from when Cache.batch() was exposed? |
| 18:37 | <JakeA> | wanderview: Alex is against it, so probably not. It'll just be part of the algorithm to describe the atomic bits. |
| 18:37 | <JakeA> | wanderview: yeah |
| 18:37 | <wanderview> | JakeA: seems the algorithm supports mixed delete/put operations, but thats not exposed any more |
| 18:37 | <JakeA> | wanderview: a put involves deletes too |
| 18:38 | <JakeA> | (to remove entries that can no longer be reached) |
| 18:38 | <wanderview> | JakeA: true... |
| 18:39 | <wanderview> | JakeA: but we don't expect any kind of batch operation that can do [put:a, delete:b, put:c], right? |
| 18:39 | <wanderview> | from what you said above |
| 18:39 | <JakeA> | True |
| 18:39 | <wanderview> | thanks |
| 18:50 | <Hixie> | MikeSmit1: yt? |
| 18:50 | <Hixie> | jorendorff: yt? |
| 18:51 | <Hixie> | MikeSmit1: https://www.w3.org/accounts/request isn't working for me. I'm trying to create a test account and I never get the e-mail. |
| 18:54 | <Hixie> | jorendorff: do you have any opinions on the summary i sent es-discuss? |
| 18:55 | <jorendorff> | Hixie: haven't read it yet -- this week has been a little crazy |
| 18:55 | <Hixie> | k |
| 19:01 | <annevk_> | grrr |
| 19:01 | <annevk> | oh wow, that SHA-1 thread went over a hundred |
| 19:17 | <Hixie> | annevk: grrr? |
| 19:17 | <annevk> | Hixie: URL threads |
| 19:18 | <Hixie> | i did like the way plh basically sidestepped all my points and countered with an irrelevant thing about the API part of the spec |
| 19:29 | <caitp> | Hixie: maybe it's not worth spending time indenting that algorithm if nobody wants to implement it anyways :z |
| 19:29 | <Hixie> | heh |
| 19:34 | <Hixie> | MikeSmit1: nm, it finally came through |
| 19:54 | <cwilso> | hixie: the confluence of "any of which are welcome to join the cg if they want to make a patent commitment" and "I dunno why anyone would join the cg", as well as our previous discussions, lead me to believe you just don't care about managing (particularly: maximizing) IP commitments. Is that so? |
| 19:55 | <Hixie> | i meant that i don't know why anyone would have joined the cg before there was anything to sign |
| 19:56 | <Hixie> | but certainly it's true that I don't prioritise maximising IP commitments over spec quality. |
| 19:56 | <Hixie> | i would be horrified if anyone did |
| 19:56 | <cwilso> | that's not an either-or, nor even necessarily related. |
| 19:56 | <Hixie> | well, they're related in that one has a finite amount of time |
| 19:57 | <Hixie> | and clearly the w3c doesn't prioritise spec quality over, say, getting consensus. or paying members. |
| 19:57 | <Hixie> | (and i'm horrified by much of the w3c) |
| 19:58 | <Hixie> | maybe "disgusted" would be better than "horrified" in the two places where i used it above |
| 19:58 | <cwilso> | well, yeah, I'd say prioritizing consensus is pretty important, though I believe you disagree with me. |
| 19:58 | <Hixie> | on the topic of consensus, and more or less on that topic alone, i am in firm agreement with the late Ms Thatcher. |
| 19:59 | <cwilso> | Indeed, if I felt I had to abandon my beliefs, principles or values, I'd be disgusted too. |
| 20:01 | <cwilso> | But merely saying "screw consensus" is not a principled declaration. (As previously: when I say "concensus", I mean "rough consensus" - i.e. not unanimous consensus.) |
| 20:02 | <Hixie> | i haven't merely said that, my friend. As you well know. I've written long screeds on the reasoning behind my position. |
| 20:02 | <Hixie> | but the issue is moot in the case of the url spec anyway |
| 20:02 | <Hixie> | since we (a) have rough consensus already, and (b) the w3c is explicitly planning to not look for consensus |
| 20:03 | <Hixie> | they just want to republish our work with their logo |
| 20:03 | <Hixie> | why, i dunno. some absurd form of jealousy? |
| 20:03 | <Hixie> | it's not to get a stable form, since we have one |
| 20:04 | <Hixie> | it's not to get a place for patent commitments, since we have one of those too. One with the W3C logo on it no less. |
| 20:05 | <Hixie> | on a more productive note: anyone know if the console API is specced out anywhere? |
| 20:05 | <cwilso> | indeed, IP is not really the issue with the URL spec. I'm actually not as convinced as you there is rough consensus, though I don't think it's that far off. But the intersection of "not stable" and "not consensus based" leaves a lot of room for abuse. |
| 20:05 | <Hixie> | how can there not be rough consensus. It's literally a spec whose entire purpose is to describe what was implemented. |
| 20:05 | <caitp> | > console spec > mike's github repo? |
| 20:06 | <Hixie> | also, looking for "stable" in a web spec is _even more misguided_ than looking for consensus |
| 20:06 | <Hixie> | caitp: do you have a url? |
| 20:06 | <caitp> | http://sideshowbarker.github.io/console-spec/ |
| 20:06 | <caitp> | dunno if there's another one somewhere. |
| 20:07 | <Hixie> | that's sadly incomplete. and stable. |
| 20:07 | <Hixie> | a pretty good example of why stable sucks, in fact :-) |
| 20:07 | <Hixie> | looks like there's no spec for it, huh |
| 20:08 | <Hixie> | MikeSmit1: do you know if there's anything less stable than that with respect to a console api spec? |
| 20:08 | Hixie | is going to start using "stable" as a synonym for "stale" |
| 20:18 | <cwilso> | nice and dismissive, love it. |
| 20:21 | <erlehmann> | http://news.dieweltistgarnichtso.net/bin/jpegtruncate.html |
| 20:21 | <wanderview> | JakeA: can you help me understand QueryParams.ignoreSearch? the [[CacheQuery]] algorithm sets url.search to the empty string if this is set, but I don't see url.search being referenced anywhere... |
| 20:21 | <erlehmann> | does anyone know if i can compress the content of a data uri? |
| 20:21 | <wanderview> | also... it seems Request.url is a ScalarValueString... so its odd that it has .search and .href attributes |
| 20:21 | <erlehmann> | like, having a data uri that contains a gzipped text file? |
| 20:24 | <JakeA> | wanderview: hmm, maybe it lost something in the translation from the ts file... |
| 20:25 | <wanderview> | JakeA: I don't see those attributes being used in the ts file either... |
| 20:25 | <JakeA> | wanderview: the intention is, of ignoreSearch is true, then a request with url https://origin.co.uk/whatever?fjfjdjd will match an entry with url https://origin.co.uk/whatever?foobar |
| 20:26 | <JakeA> | wanderview: in the ts the url is parsed using new URL, the search portion of the URLs are set to an empty string |
| 20:26 | <JakeA> | (From memory) |
| 20:26 | <wanderview> | JakeA: ah, ok... the query part of the url |
| 20:27 | <wanderview> | JakeA: I'll write an issue on this... seems that needs to be fixed up if thats the intention |
| 20:27 | <JakeA> | wanderview: yeah, it's called search because of window.location.search |
| 20:27 | <JakeA> | \o/ legacy |
| 20:32 | <wanderview> | JakeA: hmm... perhaps my confusion is that Request.url is a ScalarValueString in the fetch spec |
| 20:32 | <wanderview> | JakeA: and maybe [[QueryCache]] expects it to be a url object where setting the `search` attribute changes the actual underlying value of the url |
| 20:33 | <JakeA> | wanderview: yeah, that's how it works in the TS |
| 20:35 | <wanderview> | JakeA: pardon my ignorance here, but is there a spec defined URL object? |
| 20:36 | <wanderview> | ah, yes |
| 20:36 | <wanderview> | https://developer.mozilla.org/en-US/docs/Web/API/URL |
| 20:37 | <wanderview> | annevk: is there a reason we don't use the URL object (http://url.spec.whatwg.org/#api) for Request.url in the fetch spec? |
| 20:49 | <jsbell> | On a slight tangent, does anyone implement URL's searchParams yet? |
| 20:49 | <Domenic> | wanderview: http://url.spec.whatwg.org/#url-apis-elsewhere |
| 20:49 | <wanderview> | Domenic: thanks |
| 20:50 | <wanderview> | jsbell: this claims chrome 32 and FF: https://developer.mozilla.org/en-US/docs/Web/API/URL#Browser_compatibility |
| 20:51 | <wanderview> | jsbell: oh... I guess not: https://developer.mozilla.org/en-US/docs/Web/API/URLUtils.search |
| 20:51 | <wanderview> | if thats up-to-date |
| 20:51 | <jsbell> | It's still a FIXME in chrome |
| 20:51 | <jsbell> | (i.e. TODO item) |
| 20:52 | <wanderview> | at the end of the day, though... this is an internal algorithm and the use of URL just seems for convenience in the spec |
| 20:53 | <JakeA> | wanderview: url properties are all strings for consistency, I believe |
| 20:54 | <wanderview> | JakeA: yea, Domenic hooked me up with the link above |
| 20:57 | <JakeA> | wanderview: ah, yes, sorry |
| 20:58 | <wanderview> | oh, np... thanks for helping me understand :-) |
| 21:03 | <Hixie> | TabAtkins: how in the world did we end up with /**/ comments working inside media="" attributes |
| 21:03 | <wanderview> | hmm... I guess I need to parse Headers.getAll("Vary") values in cases someone sticks a comma-separate value in one of the values |
| 21:33 | <TabAtkins> | Hixie: Because the syntax of media is described by CSS, and it's easier to allow /**/ comments than to add a special mode to CSS parsing that disallows them. |
| 21:33 | <Hixie> | i thought it started as a standalone syntax |
| 21:36 | <TabAtkins> | Hixie: It did, yes, back when it was just a media type. |
| 21:36 | <TabAtkins> | Then we extended it to arbitrary MQs. |
| 21:37 | <SamB__> | TabAtkins: so you had to either use the CSS tokenizer or make a huge mess in implementations? |
| 21:37 | <TabAtkins> | Yeah. |
| 21:37 | <TabAtkins> | No sense writing a custom parser when one is sitting *right there*. |
| 21:45 | <Hixie> | TabAtkins: i mean mqs were originally just their own syntax |
| 21:45 | Hixie | remembers coming up with the "only" keyword |
| 21:45 | <Hixie> | i coulda sworn we hadn't defined it as accepting comments back then |
| 21:46 | <TabAtkins> | Oh, dunno about that. If they were, it was before my time; they've been described in CSS terms as long as I've known them. |
| 21:46 | <Hixie> | so i'm surprised it ended up that comments were supported |
| 21:46 | <TabAtkins> | As in, described using the 2.1 grammar, which implicitly allows comments between any tokens. |
| 21:51 | <annevk> | Hixie: my fault |
| 21:51 | <annevk> | Hixie: the main issue being that for CSS parsing media queries was underdefined |
| 21:51 | <annevk> | Hixie: so we wondered whether we wanted two distinct parsers or just share the thing |
| 21:52 | <annevk> | Hixie: we ended up deciding to just share it |
| 21:57 | <Hixie> | annevk: i don't think it's a problem, i'm just surprised implementors did it |
| 21:58 | <TabAtkins> | You're surprised they were happy to delete code? |
| 21:58 | <Hixie> | i'm surprised they cared enough to look at the code |
| 21:58 | <TabAtkins> | There's always *someone* who cares enough. ^_^ |
| 21:58 | <Hixie> | not in my experience :-) |
| 21:59 | <TabAtkins> | You just haven't found the right someone. Someday you'll meet your soulmate. |
