| 00:04 | <kamome_> | Hixie: Also reportet to schema.org (and answered a few questions on SE/SO) |
| 03:35 | <roc> | wow, James Salsman is still alive! |
| 03:37 | <roc> | at CMU in the mid-90s Salsman was already fading into legend |
| 06:13 | <annevk> | jgraham: I'm not sure I follow |
| 06:14 | <annevk> | Seems StartSSL and sleevi_ had a short Twitter exchange, lol |
| 06:30 | <hsivonen> | I'm somewhat uneasy about using StartSSL and going crazy with minting certs that cost nothing to mint after identity validation, because each cert minted there *might* cost $25 later if there's a need to revoke |
| 06:30 | <hsivonen> | still, for wildcards, $60 plus maybe $25 later is better than $150 up front |
| 06:31 | <hsivonen> | for non-wildcards, $15 up front may be better than $25 later if it happens to be a Heartbleed year |
| 06:32 | <hsivonen> | FWIW, the reason why my site doesn't have a StartSSL cert is that I got an "XMPP cert" from StartSSL for hsivonen.fi and then tried to mint a Web server cert for hsivonen.fi |
| 06:32 | <hsivonen> | StartSSL didn't allow me to mint two certs for hsivonen.fi and wanted me to revoke the first one |
| 06:33 | <hsivonen> | the revocation would have cost more than a new cert from Gandi |
| 06:33 | <hsivonen> | dunno if this works differently when you've been identity validated for $60 |
| 06:39 | <annevk> | I think I would still have to pay for revocation |
| 06:40 | <annevk> | It seems like they could automate revocation as well though and make that free too |
| 06:41 | <hsivonen> | annevk: charging for revocation is consistent with their business model of charging for things that cost them money |
| 06:41 | <hsivonen> | annevk: the revocation infrastructure costs them money |
| 06:41 | <annevk> | Because of the traffic? |
| 06:42 | <hsivonen> | which is sad, considering how useless the revocation infrastructure is currently |
| 06:42 | <hsivonen> | annevk: right |
| 06:42 | <annevk> | I saw revocation basically only works if you use EV |
| 06:42 | <annevk> | At least in 2013 |
| 06:42 | <hsivonen> | annevk: I believe that's correct |
| 06:44 | <hsivonen> | (I really need to find the time to add SNI support to Validator.nu) |
| 06:44 | <annevk> | hsivonen: you implement TLS yourself? |
| 06:44 | <hsivonen> | (the main reason why validator.nu isn't behind https already is the ridicule of it not being able to validate itself if it were) |
| 06:45 | <hsivonen> | annevk: no. I mean upgrading enough things to make SNI work |
| 06:45 | <annevk> | Why could it not validate itself? |
| 06:45 | <hsivonen> | annevk: including upgrading HttpClient, whose new version is API-incomptabile and requires me to rewrite a bunch of stuff |
| 06:46 | <hsivonen> | annevk: I'm not going to buy IP addresses for each host name, so it would be SNI, but V.nu can't connect with SNI as a client |
| 06:46 | <hsivonen> | for the server piece, I'd probable terminate TLS in nginx instead of Java |
| 06:46 | <annevk> | hsivonen: oh I see, so you could not validate whatwg.org once we'd add HSTS |
| 06:47 | <hsivonen> | annevk: the validator doesn't know about HSTS, but it would follow a redirect and then fail |
| 06:47 | <annevk> | That's what I meant, yes |
| 06:48 | <hsivonen> | also, to make Java approximate browser behavior as a clien, I'd need to upgrade to OpenJDK 8 |
| 06:49 | <hsivonen> | last I checked, it hadn't been packaged for Ubuntu yet |
| 06:49 | hsivonen | goes check again |
| 06:49 | <hsivonen> | (still better than implementing UTF-8 myself for PHP way back when) |
| 06:50 | <hsivonen> | still not openjdk-8 in trusty |
| 06:51 | <annevk> | hsivonen: did StartSSL want you to mint a certificate for both XMPP and web usage? |
| 06:52 | <hsivonen> | annevk: their UI suggests that XMPP certs and Web certs are different |
| 06:53 | <hsivonen> | annevk: Prosody's tools suggest the same |
| 06:53 | <hsivonen> | annevk: I *think* XMPP certs have some weird OIDs |
| 06:53 | <hsivonen> | annevk: I don't know why |
| 06:53 | <annevk> | hsivonen: agreed, so I'm wondering what they wanted you to do for the XMPP certificate |
| 06:54 | <hsivonen> | annevk: probably the expectation was that I'd mint it for a different host name or something |
| 06:54 | <hsivonen> | annevk: dunno if that part of the UI was well tested |
| 06:54 | <hsivonen> | the UI for sure doesn't warn you about stuff like this |
| 06:55 | <annevk> | It's interesting that there were still people involved for that part |
| 06:55 | <annevk> | I thought that once you had a domain validated, you could just issue away |
| 06:56 | <hsivonen> | annevk: I don't think there were any people involved |
| 06:57 | <hsivonen> | the UI just said that if I wanted a Web server cert for hsivonen.fi, I should revoke the XMPP cert I had already minted |
| 06:57 | <hsivonen> | with no UI warning about traps like this when minting the XMPP cert |
| 06:57 | <annevk> | That is really too bad |
| 06:58 | <annevk> | I think I only want web so I'm probably good. Although maybe at some point I can figure out email... |
| 07:09 | <annevk> | mounir: it's extremely unclear what commit actually fixed my issues with screen orientation |
| 07:09 | <annevk> | mounir: the handling of comments was rather terrible from a reviewer's perspective |
| 08:01 | <zcorpan> | MikeSmith: the "HTML - <img>" bugzilla bug doesn't reproduce in bugzilla.mozilla.org afaict |
| 08:06 | <MikeSmith> | zcorpan: ok |
| 08:07 | MikeSmith | considers looking through changelogs to see when it was fixed |
| 08:08 | <hsivonen> | Ubuntu Utopic has openjdk-8 in Universe |
| 08:08 | <hsivonen> | should I host V.nu on a prerelease OS? |
| 08:09 | <hsivonen> | surely it would be natural to backport openjdk-8 to Trusty |
| 08:09 | <hsivonen> | but it's not there |
| 08:15 | <MikeSmith> | hsivonen: I run debian testing on my server, so I'd vote yes |
| 08:15 | <MikeSmith> | though if you do it I'd suggest you don't have it set to do (apt) autoupdate |
| 08:19 | <hsivonen> | MikeSmith: wow. living on the edge |
| 08:23 | <annevk> | Domenic: http://jiggity.com/steve.html is nice |
| 08:23 | <annevk> | Domenic: Steve Jobs fanfic |
| 08:26 | <tantek> | annevk that's amazing |
| 08:28 | <ondras> | 844 passing (35s) |
| 08:28 | <ondras> | 28 failing |
| 08:28 | <ondras> | promises tests be damned. |
| 08:38 | <ondras> | Domenic: so now my promise impl passes all 872 tests, but the test runner seems to "freeze" after reporting all success. Looks like there is an infinite eventloop (strace reports epoll_wait calls)... |
| 08:38 | <ondras> | Domenic: do you have any suggestion regarding this? Is it possible that this behavior is caused by my impl? |
| 08:39 | <ondras> | (I am using the "promises-aplus-tests" node package) |
| 09:04 | <ondras> | Domenic: ah, somehow "adopting state of another promise" results in an infinite settimeout loop (in my impl) while passing the test suite .) |
| 09:14 | <niloy> | Is there anyway I can get window.performace.timing info for ajax calls? |
| 09:28 | <zcorpan> | MikeSmith: the <hgroup> example in http://html5.org/r/8759 shows some unimplemented things in v.nu |
| 09:30 | <mounir> | annevk: sorry about that, I think I used another PR to fix the issue you pointed |
| 09:31 | <mounir> | annevk: I might have "CC'd" you, not 100% certain |
| 09:38 | <hsivonen> | Is this Blink behavior supported by the spec http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3177 ? |
| 09:38 | <hsivonen> | I want to argue we should put "bar" in the HTML namespace |
| 09:39 | hsivonen | goes read the spec |
| 09:43 | <hsivonen> | aargh. Blink's behavior is correct per spec |
| 09:43 | <hsivonen> | I'm not sure I like this |
| 09:47 | <hsivonen> | Hixie_: is it intentional that the HTML fragment parsing algorithm can now create nodes that aren't in any of the HTML, SVG and MathML namespaces? |
| 09:54 | <jgraham> | hsivonen: Woah |
| 09:56 | <jgraham> | Although I guess it somewhat matches what you might expect |
| 10:13 | <zcorpan> | hsivonen: that's not what i expected at least |
| 10:24 | <annevk> | It's somewhat unexpected that the <div> is still in the HTML namespace |
| 10:26 | <jgraham> | Yeah, the fact that it's different for the two elements is pretty weird |
| 10:29 | <Domenic> | ondras: wow! If you can write a test that fails would love to have that in the suite :) |
| 11:00 | <annevk> | Anyone have a reference to that post where Hixie_ references all the editions of the <canvas> spec? |
| 11:04 | <Ms2ger> | Don't find anything in my inbox |
| 11:13 | <jgraham> | annevk: Got any time for https://critic.hoppipolla.co.uk/r/2555 ? (seems to be a small XHR test fixup) |
| 11:20 | <annevk> | jgraham: done |
| 11:20 | <annevk> | jgraham: would be nice if it automatically merged afterwards if it could |
| 11:22 | <jgraham> | Yeah, there was an idea to have a "Merge" button in the critic UI, but it didn't happen because I didn't figure out the permissions issues. Although maybe it could just work with the critic bot user. |
| 11:24 | <Ms2ger> | But travis |
| 13:49 | <MikeSmith> | zcorpan: about <hgroup> what's an example of something that's not implemented in v.nu? |
| 13:49 | <MikeSmith> | (the escaped markup in the source is pretty hard to read) |
| 13:50 | MikeSmith | looks at the corresponding rendered part in the spec |
| 13:50 | <zcorpan> | MikeSmith: onclose, method=dialog, inputmode, autocomplete |
| 13:51 | <MikeSmith> | ah |
| 14:16 | <MikeSmith> | where is onclose specified? |
| 14:17 | <MikeSmith> | nm |
| 14:18 | <Ms2ger> | What onclose? |
| 14:18 | <Ms2ger> | Oh, dialog |
| 14:19 | <foolip> | mounir: pong, a few days later :) |
| 14:39 | <MikeSmith> | zcorpan: one down https://github.com/validator/syntax/commit/759f868090c28137f420bde9b139ec6da21ef121 and looking at the rest now |
| 14:39 | <zcorpan> | MikeSmith: awesome! |
| 14:55 | <annevk> | http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0099.html and this is only identified now? |
| 14:55 | <annevk> | o_O (need a bigger O) |
| 14:57 | <jgraham> | Well I think they got the wrong idea tbh. What they should work on is not having "errata" as a thing. |
| 14:58 | <MikeSmith> | hmm, "Bad value walletSetup.continue(this.returnValue) for attribute onclose on element dialog: missing name after . operator" |
| 14:58 | <jgraham> | It's probably worth considering why bz got that response when the same thing has been said in different ways for a number of years |
| 15:04 | <annevk> | Well yeah, errata as such is not really the problem. It's specifications being out of date |
| 16:06 | <Hixie_> | jgraham: he looks to me to have gotten the same response as everyone else |
| 16:07 | <Hixie_> | jgraham: "oh so problem is [restate problem in a way that's easier to do in a bureaucracy]*? *don't do anything*" |
| 16:07 | <Hixie_> | uh, with one less * |
| 16:08 | <Hixie_> | annevk: http://damowmow.com/temp/canvas-specs but please copy-paste rather than referencing, and note that that is itself somewhat out of date now |
| 16:09 | <Hixie_> | hsivonen: it is not intentional that the HTML fragment parsing algorithm can now create nodes that aren't in any of the HTML, SVG and MathML namespaces, but i must admit to not having paid enough attention to the fragment case |
| 16:12 | <jgraham> | Hixie_: Perhaps. It seemed to me that there was a lot less denying that there was an issue when an implementor who is not noted as someone with a stake in the spec-political-process came along and said "the W3C is failing me". But I could just be projecting what I thought ought to happen. |
| 16:12 | <Hixie_> | i have often felt that, in the moment, jeff has completely agreed with what i've said |
| 16:12 | <jgraham> | s/failing me/failing me, and here's a specific example/ |
| 16:13 | <Hixie_> | only to find that my request gets completely corrupted and turned into something much less useful over time, and eventually results in a change that is of no use to me |
| 16:13 | <Hixie_> | so the proof here will be in whether errata are trivial to issue six months from now |
| 16:14 | <jgraham> | It is certianly true that change has been somewhere between slow and non-existant |
| 16:14 | <Ms2ger> | That's not the question |
| 16:14 | <Ms2ger> | The question is if they are issued, not if they can be |
| 16:15 | <Hixie_> | that too |
| 16:15 | <Hixie_> | that's actually the key way in which jeff made it sound like he agreed with bz but didn't really |
| 16:15 | <Hixie_> | notice how he changed a question of fundamental priorities into a question of volume of red tape |
| 16:17 | <Hixie_> | zcorpan: man, you're awesome. thanks. (re https://www.w3.org/Bugs/Public/show_bug.cgi?id=26786 in this case, but also in general) |
| 16:25 | <zcorpan> | Hixie_: thank you :-) |
| 16:27 | <Hixie_> | i wonder why </template> gives a parse error |
| 16:28 | <Hixie_> | it shouldn't, right...? |
| 16:28 | <Hixie_> | i should test this with my parser, see what i get there... |
| 16:35 | <Hixie_> | any IE users able to test http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3099 for me? |
| 16:36 | <Domenic> | IE11 latest updates [object Event] (same task) |
| 16:36 | <Domenic> | [object PageTransitionEvent] (same task) |
| 16:36 | <Hixie_> | cool, thanks |
| 16:36 | <annevk> | Hixie_: I removed the spec splitter from html5.org btw |
| 16:37 | <Hixie_> | annevk: cool |
| 16:37 | <Hixie_> | spec splitting now happens inline with the spec generation |
| 16:37 | <Hixie_> | dunno if anyone's noticed, but that means the split version doesn't lag behind anymore |
| 16:39 | <Hixie_> | oh, same task / same task implies IE11 is buggy in its media element handling |
| 16:39 | <Hixie_> | great |
| 16:39 | <Hixie_> | ok |
| 16:46 | <Hixie_> | can anyone figure out why <!DOCTYPE HTML><template><li></template> has a parse error? |
| 16:47 | <caitp-> | is that question going to be on the exam? |
| 16:47 | <Hixie_> | yes |
| 16:49 | <Hixie_> | woah |
| 16:49 | <Hixie_> | it's a bug in my parser |
| 16:49 | <Hixie_> | but that implies two browsers have had the same exact bug |
| 16:52 | <caitp-> | a bug in the extremely complicated html parser doesn't seem unthinkable to me |
| 16:52 | <Hixie_> | this bug was trivial |
| 16:52 | <Hixie_> | i just hadn't included all the elements in the "generate all implied end tags thoroughly" logic |
| 16:52 | <Hixie_> | but i wonder why |
| 16:55 | <cwilso> | Hixie: just filed Web Audio issue on that HTML bug, feel free to close the HTML one. |
| 16:59 | <Hixie_> | coolio, thanks |
| 18:12 | <Hixie_> | annevk: any idea how i should phrase http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#concept-media-load-algorithm step 9:otherwise:1's "as nodes are inserted and removed" steps? |
| 18:50 | <dmurph> | annevk: I'm looking at the "clone" discussion in the fetch spec here: https://github.com/slightlyoff/ServiceWorker/issues/372#issuecomment-52751957 Is the design is close enough to settled to start specing and implementing? |
| 18:51 | <slightlyoff> | Yes. |
| 18:53 | <dmurph> | cool, thx |
| 19:15 | <Hixie_> | Domenic: i don't understand why an uncaught rejection should be a big deal |
| 19:16 | <Hixie_> | Domenic: if you don't want to catch it, then it should surely just be ignored, just like if you don't hook the onerror handler on an <img> element. |
| 19:19 | <ehsan> | JakeA: ping |
| 19:20 | <Domenic> | Hixie_: onerror provides a global hook for sync errors, so you don't need a try { ... } catch (e) { ... } around every code entry point. We want the same for async errors. |
| 19:24 | <zenparsing> | Hixie_ promise rejections can also arise out of standard programming bugs, like identifier misspellings and such |
| 19:26 | <Hixie_> | zenparsing: that's a bug in the design of promises, though. |
| 19:26 | <caitp-> | it is, but it isn't super likely to change |
| 19:26 | <zenparsing> | Hixie_ heh, you're not going to win that one : ) |
| 19:26 | <Hixie_> | yeah. so now that bug is turning into me having to do work to work around the bad design i already complained about. |
| 19:26 | <Hixie_> | sigh. |
| 19:26 | <Hixie_> | it's <picture> all over again |
| 19:30 | <caitp-> | :[ |
| 19:43 | <JakeA> | ehsan: hey, I'm cramming for my jsconf talk right now, then sleep. I'll organise a call to go over the API generality stuff |
| 19:44 | <ehsan> | JakeA: sounds good, I commented on the issue fwiw, nothing urgent |
| 19:45 | <JakeA> | ehsan: will reply |
| 19:45 | <ehsan> | ta |
| 20:26 | <annevk> | dmurph: yeah, everything apart from the clone() method is defined now |
| 20:27 | <annevk> | dmurph: I expect to define clone() as creating a copy of everything and a tee of the stream (not sure what that means yet, waiting for the streams primitive to be better defined for that) |
| 20:27 | <annevk> | dmurph: ought to mean about the same as the request cloning that's already going on in UAs today |
| 20:28 | <annevk> | Hixie_: the insertion and removing steps should give enough context to update the pointer |
| 20:34 | <zenparsing> | Hixie_ the problem is we have no usable definition of an "asynchronous program error" wrt promises (b/c a rejection could always be handled "later") - but i'm going to try anyway... |
| 20:34 | <zenparsing> | define a "user entry point" to be any function call where the host (HTML) is calling into user code |
| 20:34 | <zenparsing> | an "asynchronous program error" occurs when a user entry point returns a promise which rejects |
| 20:34 | <zenparsing> | so this triggers window.onerror: elem.onclick = evt => Promise.reject(new Error("asdf")) |
| 20:34 | <zenparsing> | so does this: elem.onclick = async evt => window.loction = await somethingAsync(); |
| 20:35 | <zenparsing> | (note async and the spelling error) |
| 20:36 | <zenparsing> | ...probably doesn't work, but an interesting idea anyway |
| 20:37 | <TabAtkins> | Hixie_: What Twitter client do you use? Almost none of your replies are actually linked to the tweet you're replying to. |
| 20:37 | TabAtkins | just happens to be looking at your Twitter page today. |
| 20:38 | <TabAtkins> | Oh, never mind, those were just all the "fake replies" from several years ago. Whatever you were doing then was weird. Your replies work correctly now. |
| 20:51 | <annevk> | I think back then Twitter did not have threading |
| 21:11 | <TabAtkins> | That sounds crazy. |
| 21:45 | <Hixie_> | TabAtkins: just the web site |
| 21:50 | <Hixie_> | xhr with promises: would it be something like xhr.send(); xhr.ready.then(...); ? |
| 21:50 | <Hixie_> | or .loaded.then() ? |
| 21:52 | <TabAtkins> | .loaded, I guess? |
| 21:56 | <TabAtkins> | It turns out that running a single regex per line instead of 20, when processing a large file, actually saves a signfiicant amount of time. |
| 21:56 | <Hixie_> | that depends on the regexps in question |
| 21:57 | <TabAtkins> | This is a simple regex, I was just constructing them fresh every time. |
| 21:57 | <TabAtkins> | Basically I shaved a second off of Bikeshed running time. |
| 21:57 | <TabAtkins> | Because I finally put together some profiling. |
| 21:57 | <Hixie_> | ah, well, sure |
| 22:04 | <Hixie_> | man, desigining promise-based apis with this whole "exceptions result in rejection" thing is annoying |
| 22:04 | <Hixie_> | it just doesn't map to the existing model at all |
| 22:05 | <Hixie_> | like, consider XHR |
| 22:05 | <Hixie_> | you really want rejection to mean "the result was not 2xx" |
| 22:05 | <Hixie_> | but now it also has to mean "send() was called when the state was not OPENED" |
| 22:05 | <Hixie_> | since it's anathema to have send() throw, apparently |
| 22:06 | <Hixie_> | even though it's pointless for that to be in a promise rejection since you know it synchronously and aren't ever going to try to catch it |
| 22:07 | <TabAtkins> | I thought that we weren't promisifying xhr, we were replacing it with fetch(), which doesn't have the same state-management issues. |
| 22:08 | <Hixie_> | xhr's just an example, the same problem occurs with lots of things |
| 22:08 | <Hixie_> | e.g. requestAutocomplete |
| 22:08 | <Hixie_> | rejection can be for any of the reasons that autocompleteerror currently fires |
| 22:08 | <TabAtkins> | Yeah. |
| 22:08 | <Hixie_> | but also for all the reasons that requestAutocomplete() currently throws |
| 22:09 | <TabAtkins> | Sure. |
| 22:09 | <Hixie_> | which are currently separate for good language design reasons |
| 22:09 | <Hixie_> | but with promises... |
| 22:09 | <Hixie_> | and actually fetch() does have the same problem. it doesn't reject if there was a network error. |
| 22:10 | <TabAtkins> | Handling two kinds of errors with sync throwing and async error events have the same usability problems the promise people are complaining about. |
| 22:11 | <Hixie_> | no it doesn't, because you never need to worry about the sync exceptions |
| 22:11 | <Hixie_> | nobody ever tries to catch them |
| 22:11 | <Hixie_> | and if they occur, your code just ends, it doesn't start running random code with invalid input |
| 22:11 | <TabAtkins> | Then don't worry about them. |
| 22:11 | <Hixie_> | but with rejection, you have to! |
| 22:11 | <Hixie_> | because now your code expecting a string rejection reason might get an exception rejection reason instead |
| 22:11 | <Hixie_> | or whatever |
| 22:12 | <TabAtkins> | You'll just throw or something when you end up trying to operate on the weird error anyway. |
| 22:13 | <Hixie_> | not necessarily |
| 22:13 | <Hixie_> | (mostly that's a result of JS lacking type checking) |
| 22:13 | <Hixie_> | (which is another language bug imho :-) ) |
| 22:13 | <TabAtkins> | Agreed. |
| 22:17 | <jgraham> | I think Hixie has a point; if you think that using exceptions for flow control is bad and that using rejections for flow control is good (which seems to be part of the promise model), then using rejections to replace exceptions is bad |
| 22:18 | <Hixie_> | oh, wait, fetch() does reject the promise for network error |
| 22:18 | <Hixie_> | so fetch() has _exactly_ the problem i described for xhr |
| 22:19 | <Hixie_> | if you call fetch({ method: 'get', url: '/' }).then(a, b); where b() is some function to handle errors, you'll appear to always get a network error |
| 22:19 | <Hixie_> | but actually, you're not getting a network error |
| 22:19 | <Hixie_> | you're getting a type error because the arguments were type checked as bad |
| 22:20 | <Hixie_> | and there's no way i can see to distinguish those two completely unrelated cases |
| 22:21 | <Hixie_> | even if there was, e.g. because fetch() rejected with NetworkError instead of TypeError, you'd still be SOL. (a) because you wouldn't be able to get the network error information (e.g. status code, which XHR gives you), and (b) because you would never think to check for TypeError, so you'd assume it was a NetworkError and would _still_ think you always had a bed network |
| 22:21 | <Hixie_> | Domenic: ^ that's why you're wrong. |
| 22:22 | <Hixie_> | (the correct was to call it, for those who are wondering, is fetch(new Request({ method: 'get', url: '/' })).then(a, b); ) |
| 22:24 | <Hixie_> | no wait, it's fetch(new Request('/', { method: 'get' })).then(a, b); |
| 22:24 | <TabAtkins> | How'd you get any network error information if it failed at the type-checking stage? |
| 22:24 | <Hixie_> | fetch() rejects with TypeError for a network error |
| 22:24 | <Hixie_> | and IDL rejects any promise-returning method with TypeError for an argument type error |
| 22:25 | <Hixie_> | either way, you get b() called with TypeError |
| 23:13 | <pdescham49> | Whats the deal with the picture element? |
| 23:13 | <TabAtkins> | pdescham49: What do you mean? |
| 23:13 | <pdescham49> | why are they addng styling logic in the dom? |
| 23:13 | <pdescham49> | when it can all be handled in css media queries? |
| 23:13 | <TabAtkins> | ??? |
| 23:13 | <pdescham49> | it seems crazy to me maybe I am a purist but i believe all styling should exist in css and not in the markup |
| 23:13 | <TabAtkins> | There's no styling in <picture> |
| 23:13 | <pdescham49> | i get that it's not really styling but it's ths styling conditions. min-width etc. |
| 23:13 | <TabAtkins> | ...yes? |
| 23:13 | <TabAtkins> | Media Queries aren't CSS. |
| 23:13 | <TabAtkins> | They're used in various places. |
| 23:13 | <pdescham49> | but i am sorry I just don't see the advantage in a picture element when you can do it all in css |
| 23:13 | <TabAtkins> | You can't do responsive images in CSS. |
| 23:13 | <pdescham49> | yes you can. |
| 23:13 | <TabAtkins> | (You can do some of it via the image-set() function, but only 1x/2x style stuff.) |
| 23:13 | <TabAtkins> | CSS also isn't friendly with the preloader. |
| 23:13 | <TabAtkins> | You want images to start loading asap, and if you have to first wait for a stylesheet to load, that's a significant delay on mobile devices. |
| 23:13 | <TabAtkins> | pdescham49: I'm one of the editors of the <picture> spec, and let me tell you, "Why not Javascript?" and "Why not CSS?" are the most common questions we get. We, um, thought of it already. |
| 23:13 | <pdescham49> | Years of battling inline css in the dom has me jaded |
| 23:13 | <pdescham49> | i see a future of more and more styling in the dom. |
| 23:14 | <pdescham49> | startng with this pictue element. |
| 23:14 | <TabAtkins> | That's cool, but seriously, there's no way around the problems. |
| 23:15 | <TabAtkins> | Unless you're okay with images not even *starting* to download for a second or more. |
| 23:15 | <pdescham49> | What is the problem? short of prefetch. |
| 23:15 | <TabAtkins> | That's the problem. |
| 23:20 | <pdescham49> | correct me if i am wrong but the issue i saw it as described was that the browser is requesting more then in needs to. |
| 23:20 | <pdescham49> | in my css only solution in a responsice design with an image tag in only requests the resrouce as needed |
| 23:20 | <TabAtkins> | Depends on how you're "solving" it. If you "solve" it by having a small source in the HTML, and then providing the info to select the proper source in CSS, you double-request. If you do it entirely in CSS, you only send a single request, but you send it late. |
| 23:20 | <pdescham49> | anyhow. :) I've been a html developer for the last 20 years professionally. and this worries me :( |
| 23:20 | <TabAtkins> | (After fetching/parsing/applying the stylesheet.) |
| 23:20 | <pdescham49> | can I send you some code / benchmarks next week? |
| 23:22 | <TabAtkins> | We are aware of the problems of having MQs duplicated between multiple <picture> elements and the stylesheets; changing one of your breakpoints means you have to update it in N places. We plan to fix this with MQ variables, so you can set up the MQ once and then refer to it in every place you need it. |
| 23:22 | <TabAtkins> | Send it to the Responsive Images CG list. |
| 23:22 | <TabAtkins> | But fair warning, you're not raising anything new. |
| 23:22 | <pdescham49> | 10-4 |
| 23:22 | <pdescham49> | thank you sir for the chat.. |