| 01:20 | <gavinc> | yay, DOM4 HTML datatype for RDF preposed http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0222.html |
| 01:22 | <gavinc> | proposed too |
| 03:06 | <MikeSmith> | Hixie: w3c systems team tells me that they're having trouble getting hypermail to recognize the format of the online whatwg archives |
| 03:06 | <MikeSmith> | perhaps due to missing Received headers |
| 03:06 | <Hixie> | weird |
| 03:06 | <Hixie> | ah maybe |
| 03:07 | <Hixie> | can't they fake them or something? |
| 03:07 | <MikeSmith> | they are wondering if you have the original mobx |
| 03:07 | <MikeSmith> | maybe |
| 03:07 | <Hixie> | i have nothing |
| 03:07 | <MikeSmith> | OK |
| 03:07 | <Hixie> | sorry :-( |
| 03:08 | <MikeSmith> | no problem |
| 03:08 | <MikeSmith> | I'm sure we'll get it figured out |
| 03:32 | <kennyluck> | Hixie, why don't you just make a mbox out of your whatwg folder? |
| 03:32 | <kennyluck> | (Or whoever has all the mails) |
| 03:32 | <kennyluck> | Hixie, why don't you just make a mbox out of your whatwg folder? |
| 03:32 | <kennyluck> | (Or whoever has all the mails) |
| 03:33 | <Hixie> | i certainly don't have all the e-mails |
| 03:33 | <Hixie> | i delete them once i've replied to them :-) |
| 03:33 | <Hixie> | dunno if anyone else does |
| 03:33 | <othermaciej> | Hixie: I agree that "set" is not the best attribute name |
| 03:34 | <othermaciej> | I was thinking maybe src-set or srcset or something if the parallel to image-set is actually worthwhile |
| 03:34 | <Hixie> | yeah |
| 03:34 | <Hixie> | srcset might work |
| 04:46 | <othermaciej> | hmm I guess this applies to <input type=image src> and <video poster>, is it also required for the case of using <object> to reference an image (e.g. to be able to have a structured textual alternative)? |
| 04:47 | <othermaciej> | also in theory <command icon> but who knows when/if anyone will implement <command> |
| 05:05 | <tantek> | yay for another microsyntax! |
| 05:05 | <tantek> | othermaciej, you mean <object data> ? |
| 05:06 | <othermaciej> | tantek: yes, <object data> in the specific case of using it to refer to an image (though I guess you don't even know that up front and it's not clear what scale factor would mean for plugin content or an HTML document) |
| 05:10 | <Hixie> | othermaciej: i dunno that i'd worry about those |
| 05:12 | <othermaciej> | it certainly seems useful for poster frames |
| 05:12 | <othermaciej> | there is no obvious alternative in that case |
| 05:13 | <othermaciej> | for <input type=image> I guess you could use a client-side image map instead as an arguably preferable alternative |
| 05:13 | <tantek> | othermaciej - why limit to images? |
| 05:13 | <tantek> | (for <object data> that is) |
| 05:13 | <tantek> | at different scales you might decide say a raster vs. a vector graphic may make more sense. |
| 05:14 | <tantek> | and if it's a raster graphic, like SVG, it might also be interactive, if it happens to be an interactive medium |
| 05:14 | <othermaciej> | tantek: the semantic is that it both selects based on device pixel ratio, and scales by that factor |
| 05:14 | <othermaciej> | I can see how you might use a vector image as one of a set, but <img> with an SVG source caters to that |
| 05:15 | <othermaciej> | I'm not sure how it would make sense to select one of several HTML files based on device scale |
| 05:15 | <tantek> | as Hixie was pointing out, sometimes bandwidth is a selection factor |
| 05:15 | <tantek> | which may also be true for a static image vs. an interactive image |
| 05:15 | <tantek> | where interactive image may be SVG, or may be an iframe |
| 05:15 | <Hixie> | othermaciej: for poster, shouldn't we just use the highest res image? i mean, the user might go fullscreen, etc |
| 05:15 | <othermaciej> | I am skeptical that bandwidth-based selection can be defined or implemented sanely |
| 05:16 | <Hixie> | yeah me to |
| 05:16 | <Hixie> | yeah me to |
| 05:16 | <Hixie> | o |
| 05:17 | <tantek> | heck, I'd even offer up network reliability as another axis |
| 05:17 | <tantek> | and both of those are real-world design problems |
| 05:17 | <tantek> | as anyone with AT&T in SF knows |
| 05:17 | <tantek> | or that goes to conferences with open/free wifi like SXSW |
| 05:17 | <tantek> | both are trivial examples of both bandwidth and reliability problems/challenges |
| 05:18 | <othermaciej> | Hixie: you could always use an over-res image, but then you have to set an explicit size when you might otherwise not need to; and also it might be wasteful of bandwidth for pages that embed many videos but expect the user not to play most |
| 05:18 | <othermaciej> | Hixie: I concede that it is a less common case than <img> |
| 05:19 | <Hixie> | yeah, worth keeping in mind, certainly |
| 05:19 | <tantek> | the one example of this kind of thing in the original image had nothing to do with dimensions or pixel density. it had to do with bandwidth. lowsrc |
| 05:19 | <othermaciej> | tantek: network bandwidth, latency and reliability are all useful things to know, but they are hard to define or compute in a sane way |
| 05:19 | <Hixie> | i'm a little reluctant to go all-in and define a solution for everything at once |
| 05:19 | <tantek> | original img |
| 05:20 | <tantek> | Hixie, I didn't claim to have or know of any kind of easy/simple solution. |
| 05:20 | <othermaciej> | tantek: the one case where there's an attempt to use them over the network is for adaptive video streaming, which intrinsically deals with the fact that these properties change unpredictably over time |
| 05:20 | <Hixie> | i was responding to othermaciej about poster=, data=, etc |
| 05:21 | <othermaciej> | if srcset works out it would not be a huge deal to later define <video posterset> or <input type=image srcset> |
| 05:21 | <othermaciej> | (or whatever the name ends up being |
| 05:21 | <Hixie> | yeah |
| 05:21 | <othermaciej> | (or whatever the name ends up being |
| 05:21 | <Hixie> | yeah |
| 05:23 | <alystair> | what's the core issue being discussed here? |
| 05:23 | <Hixie> | responsive web design, subsection images |
| 05:25 | <alystair> | Isn't responsive design mostly a solved CSS ordeal? Also sprites? |
| 05:25 | <alystair> | Isn't responsive design mostly a solved CSS ordeal? Also sprites? |
| 05:26 | <tantek> | alystair - two things. 1. except when images are content rather than just presentational, and 2. many/most of the CSS solutions fail to avoid downloading all variants anyway. |
| 05:26 | <tantek> | so no, responsive design is not really "solved". there are some hacks. |
| 05:31 | <alystair> | seems like something that could be solved at a level below html? eg. some sort of header being sent and server can shoot back other files? (if we are discussing the high density display issue) |
| 05:36 | <tantek> | alystair, the general pattern of "some sort of header being sent and server can shoot back other files" is AFAIK called CONNEG AKA "content negotiation" and has largely been decided to be a near complete failure. |
| 05:37 | <tantek> | Hixie, for the set attribute, why not simply re-use CSS style declaration syntax? |
| 05:40 | <tantek> | e.g. putting urls inside a url() function, and then using ; delimited property:value declarations |
| 05:40 | <tantek> | group with { } as necessary |
| 05:53 | <othermaciej> | tantek: I presume in part to align with http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html |
| 05:55 | <tantek> | othermaciej - note that Ted advocates url(foo-lowres.png) rather than just a naked foo-lowres.png |
| 05:56 | <tantek> | (in the CSS variant) |
| 05:56 | <tantek> | doing so in the set="" attribute variant makes parsing simpler for that also. |
| 05:57 | <othermaciej> | tantek: yeah, I think the CSS variant should let you drop url(), but point taken |
| 06:01 | <tantek> | it does feel like the "set" syntax is just a "light" syntax for writing mediaqueries |
| 06:25 | <othermaciej> | tantek: kind of, yes - in practice using media queries to do the image resolution thing turns out to be too awkward |
| 06:25 | <tantek> | indeed |
| 06:25 | <othermaciej> | at the CSS level it's just syntactic sugar |
| 06:25 | <tantek> | or vinnegar |
| 07:02 | <niloy> | firefox applying same origin policy for web fonts is very annoying, doesnt work well with CDN |
| 07:41 | <odinho> | yay for getting something speced like srcset. |
| 07:42 | <zcorpan> | srcset? |
| 07:43 | <hober> | zcorpan: <img srcset="foo.jpg 2x" src=bar.jpg> |
| 07:43 | <odinho> | zcorpan: http://junkyard.damowmow.com/507 |
| 07:43 | <hober> | speaking of which, Hixie: I don't remember if I mentioned it on whatwg |
| 07:44 | <hober> | Hixie: I'll post to whatwg next week (CSS F2F this week). |
| 07:44 | <odinho> | odinho == Velmont, btw, -- I found out I could just use this name from work and Velmont from home :P |
| 07:44 | <Hixie> | hober: don't bother, i'm about to reply to the relevant thread subsubing your mail |
| 07:44 | <hober> | Hixie: I don't think you need the w & h bits. |
| 07:45 | <Hixie> | subsumingh |
| 07:45 | <Hixie> | subsuming |
| 07:45 | <hober> | Hixie: otherwise this looks a lot like what i have written up for html |
| 07:45 | <hober> | I was going with srcset |
| 07:45 | <Hixie> | yeah, that's not a coincidence :-) |
| 07:45 | <hober> | for a while i had src-set, but hyphens are weird in html attr names |
| 07:45 | <Hixie> | yeah |
| 07:45 | <Hixie> | anyway i expect to spec that tomorrow |
| 07:46 | <Hixie> | in other news |
| 07:46 | <Hixie> | i thought position:absolute;left:0;right:0;margin:auto;width:auto; would shrink wrap |
| 07:46 | <Hixie> | am i wrong? |
| 07:46 | <odinho> | hober: earlier prop was different http://junkyard.damowmow.com/506 -- then someone said it should look more like your earlier proposal on csswg. |
| 07:46 | <hober> | Hixie: i'll have to think about the algorithm you have here, to see how it matches what i've been working on |
| 07:47 | <hober> | odinho: oh, jebus. src-template. ewwwwh. :) |
| 07:47 | <Hixie> | hey! |
| 07:47 | <Hixie> | it's not THAT bad |
| 07:47 | <odinho> | :P |
| 07:47 | <Hixie> | :-P |
| 07:47 | <Hixie> | jeez |
| 07:48 | <hober> | fwiw hyatt wanted to do something like that |
| 07:48 | <hober> | though i think his idea was less ugly :) |
| 07:51 | <hober> | tantek othermaciej: I think in CSS we should simply allow any <image> in the image-set syntax, which would let you have "foo.png" or url(foo.png) etc. etc., but only used url() in examples to keep things simple |
| 07:57 | <hober> | Hixie: i went ahead and sent my drafted-quite-a-while-ago proposal to the whatwg list. :) |
| 07:58 | <Hixie> | hober: k, i'll take a look. i hope you won't be offended if my reply doesn't reference it since i've already written it based on your www-style mail :-) |
| 07:58 | <hober> | yeah, no problem. :) |
| 08:00 | <hober> | i guess i should get around to writing the epic "why <picture> is a terrible idea" email |
| 08:01 | <jgraham> | Hixie: BTW did you answer my question about spinning the event loop? |
| 08:01 | <odinho> | Better preemtively buy some popcorn then. |
| 08:01 | <Hixie> | jgraham: yes |
| 08:01 | <Hixie> | jgraham: you didn't like my answer though |
| 08:01 | <hober> | odinho: :) |
| 08:02 | <jgraham> | Hixie: You were going to check on the followup about load events |
| 08:02 | <Hixie> | jgraham: oh, right. yeah, i looked it up, and i was correct in my description. |
| 08:03 | <Hixie> | jgraham: the way the spec is phrased, as soon as there's nothing left blocking, the task is queued to continue on |
| 08:03 | <Hixie> | jgraham: even if something else blocking is immediately introduced |
| 08:07 | <jgraham> | OK, so you can't implement "spin the event loop until /condition/" with a list of functions that run each time the event loop is run, they have to be run… well actually I don't know what the smaller atomic unit iun the spec is |
| 08:09 | <jgraham> | s/implementation/hypothetical implementation/ |
| 08:10 | <jgraham> | Oh, I didn't say implementation |
| 08:10 | <jgraham> | Sigh |
| 08:10 | <jgraham> | So what is the atomic unit? |
| 08:13 | <Hixie> | if any of the definitions rely on anything being atomic, and the thing in question isn't described as happening "atomically", they're broken |
| 08:14 | <Hixie> | short of that, the atomic unit is something like CPU cycle. |
| 08:14 | <jgraham> | Hixie: I still don't understand then. Sorry if I am being thick :) |
| 08:14 | <Hixie> | planck time |
| 08:14 | <jgraham> | Well I can't check if /condition/ is true once per CPU cycle |
| 08:15 | <Hixie> | turns out, for all the conditions, you don't need to |
| 08:15 | <Hixie> | unless i made a mistake |
| 08:15 | <jgraham> | OK, so the concrete case I was looking at was stuff blocking the load event |
| 08:15 | <Hixie> | right |
| 08:16 | <Hixie> | so you can implement that using a counter |
| 08:16 | <Hixie> | and whenever you change it to zero, set a flag |
| 08:16 | <jgraham> | OK |
| 08:17 | <jgraham> | Well if that's how it's supposed to work, it is possible to make it work that way |
| 08:17 | <jgraham> | But it wasn't how I imagined the model from what it says in the spec |
| 08:17 | <Hixie> | yeah, that's a different question |
| 08:17 | <Hixie> | it's what the spec says |
| 08:18 | <Hixie> | whether the spec is right, i dunno |
| 08:18 | <Hixie> | you shouldn't imagine things, just read what the spec says :-P |
| 08:18 | <jgraham> | The spec isn't always 100% clear :p |
| 08:18 | <Hixie> | in other news, shimming <form method=dialog> is surprisingly harder than it looks |
| 08:19 | <Hixie> | jgraham: file a bug or send mail if there's something i can clarify, always happy to try to do that |
| 08:20 | <jgraham> | Hixie: Sure. Thanks for being patient :) |
| 08:20 | <Hixie> | np, sorry for writing a crappy spec :-) |
| 08:20 | <Hixie> | we really still have no way for JS to access the form data set on submission? |
| 08:21 | <Hixie> | who's running this show, a clown? |
| 08:23 | <jgraham> | Heh |
| 09:52 | <annevk> | gavinc: btw, for canonical stuff, you can prolly use DOM's isEqualNode() |
| 09:52 | <annevk> | gavinc: btw, for canonical stuff, you can prolly use DOM's isEqualNode() |
| 09:59 | <annevk> | Hixie: people did ask about accessing the contents of FormData |
| 10:00 | <annevk> | Hixie: I wasn't quite sure whether that would be the correct solution |
| 10:22 | <jgraham> | hsivonen_: Do you know anything about how gecko decides whether to block onload for CSS resources? |
| 10:54 | <hober> | annevk: you might enjoy http://lists.w3.org/Archives/Public/www-style/2012May/0409.html |
| 10:56 | <annevk> | hober: it's kind of unbelievable it even has to be discussed given how many people implemented it and how often it's used already |
| 10:57 | <hober> | i know, right? |
| 10:57 | <hober> | it's *crazy* |
| 11:00 | <annevk> | and the alternative is not exactly easier to author |
| 11:00 | <annevk> | (understatement) |
| 11:36 | <odinho> | Meh, you got me into the black hole of reading www-style, -- reading vendor prefixes discussion. Quite interesting but not really what I was doing. |
| 11:37 | <michel_v> | save yourself, mammal |
| 11:38 | <odinho> | I really like many of the responses, -- but I'm mostly clicking Florian's links, which I know will be good - and also reading Henri Sivonen's now. |
| 11:39 | <annevk> | reading www-style is a good way to worsen one's jetlag |
| 11:39 | <odinho> | annevk :| |
| 11:44 | <annevk> | I am curious though how that prefix discussion went |
| 11:44 | <hober> | it hasn't happened yet |
| 11:44 | <hober> | in person anyway |
| 11:44 | <hober> | the most recent thread was actually pretty good |
| 11:44 | <odinho> | Ahh. Guess we'll hear it first on w3cmemes |
| 11:45 | <hober> | i blame othermaciej for the improved light-to-heat ratio on the subject |
| 11:45 | <annevk> | :) |
| 11:46 | <odinho> | hober: The thread florian started? |
| 11:59 | <hober> | odinho: yeah |
| 12:01 | <odinho> | hober: Yea, that was what I was reading. Seems to have gotten quite much support. Which is great. |
| 12:02 | <odinho> | Anywayz. So, DOMString takes \0 with no problem, -- but doesn't really print it out in console etc. -- But I guess this is perfectly legal then: IDBObjectStore.createIndex("a\0b") ? Since it takes DOMString as argument (name of the index). |
| 12:04 | <gsnedders> | odinho: Yeah, unless the spec special-cases it. |
| 12:05 | <zcorpan> | AryehGregor: <link sizes> has "any" for vector images |
| 12:05 | <odinho> | gsnedders: OK, just wanted to double check so that I don't allow crazystuff that shouldn't be allowed. |
| 12:06 | <AryehGregor> | zcorpan, why would you bother specifying more than one size at all if a vector size is available? Just for fallback? I ignore the case where you want significantly different (not just rescaled) images for different resolutions, although that's a real scenario -- for larger icons you might want more detail. |
| 12:06 | <smaug____> | annevk: what is the latest spec for appcache |
| 12:07 | <smaug____> | I guess http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline |
| 12:09 | <zcorpan> | AryehGregor: dunno |
| 12:27 | <annevk> | smaug____: yup |
| 13:02 | jgraham | wishes for a single-page CSS spec |
| 13:07 | <hober> | jgraham: http://dev.w3.org/csswg/css-style-attr/ is probably as close as you're going to get |
| 13:17 | <Velmont> | lol, I'm credited as you in the webapps minutes, hober. |
| 13:18 | <odinho> | Hmm. Not so easy having two irc's open I see. I write in the wrong window :P |
| 13:19 | <hober> | Velmont: link? |
| 13:21 | <odinho> | hober: http://www.w3.org/2012/05/02-webapps-minutes.html#item10 (I'm Velmont from work) |
| 13:21 | <odinho> | hober: Stuff you said there was not said by you, but by me ;-) |
| 13:22 | <odinho> | timeless: So ... should probably update the minutes there. Don't know how to do that. |
| 13:23 | <hober> | several of the things attributed to me should be, though |
| 13:23 | <hober> | you should be more specific when you email the request to update the minutes |
| 13:23 | <odinho> | hober: Yes, just in the IndexedDB place :-) |
| 13:24 | <hober> | i would be very surprised if i got minuted saying anything about indexeddb :) |
| 13:25 | <jgraham> | Velmont: You could just be odinho here too. That would help my little brain :) |
| 13:34 | <odinho> | jgraham: I mean, -- Velmont is my private user. -- odinho is work user. I just shouldn't use the Velmont user in the #whatwg channel, it'll be less confusing :P |
| 13:34 | <AryehGregor> | Live DOM Viewer is down for me. :( |
| 13:35 | <jgraham> | AryehGregor: WFM |
| 13:36 | <AryehGregor> | Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. |
| 13:37 | <jgraham> | Oh, maybe it loaded from a cache for me |
| 13:37 | <jgraham> | It's down now |
| 14:05 | <hsivonen_> | jgraham: I know nothing about that |
| 14:11 | <lkjhl> | hi |
| 14:11 | <lkjhl> | what this is about ? |
| 14:14 | <lkjhl> | annevk hi |
| 14:17 | <limbu> | heeeellllllllloooooooooo |
| 14:17 | <zcorpan> | limbu: see http://whatwg.org/ |
| 14:30 | <limbu> | okay got it |
| 14:30 | <limbu> | your a web compnay |
| 14:32 | <hober> | nope |
| 14:33 | <odinho> | He left anyway. |
| 15:07 | <Wilto> | Oh what hello did someone say "images with disparate sources?" |
| 15:07 | <hober> | Wilto: yeah |
| 15:08 | <Wilto> | Mentioning images three times summons me like a marginally more obnoxious version of Beetlejuice. |
| 15:08 | <Wilto> | How goes it, hober? |
| 15:09 | <hober> | good good. survived the hour-long css3 grid layout discussion. now, autogeneration of super/subscript glyphs in css3 fonts. |
| 15:09 | <hober> | you? |
| 15:09 | <Wilto> | That sounds like an action packed, thrill-a-minute kinda day. |
| 15:10 | <hober> | you know it! |
| 15:10 | <Wilto> | Not bad, man, not bad. Psyched to see the respimg topic being broached; about to have my Boston-themed shirt design go up on unitedpixelworkers.com |
| 15:11 | <hober> | o rly |
| 15:11 | <Wilto> | aww yiss |
| 15:11 | hober | is from the Boston area |
| 15:11 | <Wilto> | I know, man—I seen your hat on Twitter. |
| 15:11 | <Wilto> | http://wil.to/bos-pxl.png Shh. |
| 15:12 | <Wilto> | I am already way off topic in here. |
| 15:12 | <hober> | ooooh, nice. /me might have to pick that up. |
| 15:12 | hober | needs another t-shirt like he needs a hole in the head |
| 15:13 | <Wilto> | I hear you; I’m already swimming in Pixelworkers stuff. |
| 15:13 | <Wilto> | Oh, so, original question: |
| 15:14 | <Wilto> | I’m gonna shoot an email to the respimg CG and ask them to join in the discussion on the list. Any qualms from anybody? |
| 15:16 | <hober> | if you think that would be useful |
| 15:17 | <tabatkins> | Wilto: like I mentioned on the list, the RespImg proposal is really *not* meant for the use-case that @srcset is solving. |
| 15:17 | <Wilto> | That’s why I wanted to ask first, yeah. |
| 15:18 | <Wilto> | A subset of the CG’s discussion has been around the resolution problem specifically—I didn’t know if getting those folks involved might be helpful. |
| 15:21 | <tabatkins> | It might be useful to discuss what sort of decisions you can make with the explicit resolution information. |
| 15:21 | <tabatkins> | The obvious one is retina screens. |
| 15:22 | <tabatkins> | And the second obvious one is deciding differently based on your knowledge of recent bandwidth. |
| 15:22 | <Wilto> | Right. I mean, we’ve all got the shiny new iPads front-of-mind. |
| 15:23 | <Wilto> | There’s been a lot — a _lot_ — of discussion around the idea of giving users the ability to opt out of high-resolution images regardless of bandwidth, but that’s more a subject for UAs. |
| 15:28 | <jgraham> | 10:13 < Wilto> I am already way off topic in here <-- I see you din't read the topic closely enough |
| 15:28 | <Wilto> | The "sense of logic" part? I wouldn't know logic if it bit me, man. |
| 15:53 | <tabatkins> | Wilto: I don't think that (users opting out of high-res) is something that we need to worry about from a spec perspective at all. It's a UA thing. |
| 15:54 | <Wilto> | tabatkins: Yeah, with you there. |
| 15:54 | <hober> | yup |
| 16:05 | <rafaelw_> | hsivonen: you around? any chance we can attempt to settle on a solution for DocumentFragment.innerHTML? |
| 16:06 | <annevk> | I don't think we need MQs in markup though if we get srcset |
| 16:06 | <annevk> | or the <picture> design or whatever |
| 16:12 | <Wilto> | annevk: I mean, if srcset is limited to DPI we would. |
| 16:14 | <Wilto> | I think srcset as it’s being pitched now is a great solution, it’s just a solution to a very specific issue. It doesn't really solve the greater "responsive images" problem. |
| 16:16 | <annevk> | Hixie made it work for width/height too |
| 16:16 | <annevk> | he just hasn't posted it yet but it was discussed here yesterday |
| 16:16 | <odinho> | Wilto, here ya go: http://junkyard.damowmow.com/507 |
| 16:16 | <Wilto> | Thanks, odinho. |
| 16:18 | <Wilto> | Ah, yeah, we had something along these lines in one of our early drafts. |
| 16:19 | <Wilto> | I mean, at this point, I'm almost ready to say "please just give us any solution." |
| 16:19 | <Wilto> | But that looks like an absolute nightmare for authors. |
| 16:19 | <odinho> | http://junkyard.damowmow.com/506 hixies first draft |
| 16:20 | <Wilto> | Ah man. |
| 16:20 | <Wilto> | I just... was this just done in a vacuum? |
| 16:21 | <odinho> | Nah, don't think so. I've followed the respimg stuff, -- but it's too much talk and too little action ;-) Time to get it moving. |
| 16:21 | <Wilto> | This is a solution, and I absolutely don't fault anyone for throwing ideas out there, but... we've been talking about this stuff publicly for almost a year now. We've worked through a lot of this. |
| 16:21 | <odinho> | I really like hixies 507 proposition. |
| 16:21 | <Wilto> | There's the thing. I literally have no idea what we can do beyond https://github.com/Wilto/respimg |
| 16:22 | <Wilto> | It would be obnoxious if I kept bombarding you guys with this stuff. |
| 16:23 | <Wilto> | But speaking as an author, having worked through a nearly identical idea with a group of other authors, 507/508 would be just gross to work with. |
| 16:23 | <Wilto> | In what way is it better than <picture>, seeing as it breaks with every convention for specifying alternate sources already built into markup? |
| 16:24 | <Wilto> | Not a rhetorical question there; I can absolutely be convinced. |
| 16:24 | <annevk> | it's way simpler? |
| 16:24 | <odinho> | New tag is heavy stuff. |
| 16:24 | <odinho> | what annevk said :-) |
| 16:24 | <annevk> | and yeah, you really don't want new elements for images |
| 16:24 | <Wilto> | It’s more markup, but it’s _familiar_ markup. |
| 16:24 | <Wilto> | annevk: Why? |
| 16:25 | <Wilto> | How was this scheme decided on for video, and why would a variance in media markup make sense? |
| 16:25 | <odinho> | Wilto: We are not designing HTML from scratch. |
| 16:25 | <Wilto> | No, of course not. |
| 16:25 | <odinho> | Wilto: In that scheme, doing <picture> like that might in fact be the way it was done. -- But we're not there. |
| 16:26 | <othermaciej> | Wilto: <img> can't have children, and a new element with children specifying the sources would have a hard time with degrading gracefully |
| 16:26 | <Wilto> | othermaciej: It would degrade the same as <video>, <canvas>, etc. |
| 16:27 | <odinho> | othermaciej: I think the idea was that you'd have a <img> child in there that would be the default. |
| 16:27 | <Wilto> | Specifying fallback markup, ignored by browsers that do support it. |
| 16:27 | <qubodup> | hi, I was guided here on #html |
| 16:27 | <othermaciej> | Wilto: if you had a new element analogous to <video> (<picture> I guess?) would, in addition to source-type elements, need to have an <img> child for UAs that don't support it, then also a way to have a non-image textual equivalent |
| 16:27 | <qubodup> | I am wondering why a white space char appears inside an <a href> in one case but not in another http://ompldr.org/vZG96bg |
| 16:27 | <Wilto> | othermaciej: Yep, exactly. |
| 16:27 | <odinho> | But I so prefer the simplicity of srcset="logo-hd.png 2x" |
| 16:27 | <othermaciej> | so your minimum complexity for just doing the retina display 2x scale thing would be a lot higher |
| 16:28 | <othermaciej> | instead of <img src="foo.png" srcset="foo.png 1x, foo⊙2p 2x" alt="The world's greatest foo"> |
| 16:28 | <Wilto> | So this is more or less decided, then. |
| 16:29 | <Wilto> | Based on short-term conversation and a few quick drafts, in a total vacuum, independent of all the conversation that has happened in the Community Group. |
| 16:29 | <odinho> | Wilto: Heh, if we're having a discussion we need to actually discuss :-) |
| 16:29 | <othermaciej> | you would have to do <picture><source src="foo.png" media="max-device-pixel-ratio: 1"><source src="foo⊙2p" media="min-device-pixel-ratio: 2"><img src="foo.png>The world's greatest foo</picture> |
| 16:30 | <othermaciej> | (or whatever the exact syntax would be) |
| 16:30 | <Wilto> | othermaciej: I’m not saying it’s pretty, but at least it uses already established conventions. |
| 16:31 | <othermaciej> | <video> <source> also has a first-match selection algorithm |
| 16:31 | <othermaciej> | while srcset as proposed currently attempts to do best-batch |
| 16:31 | <Wilto> | I see no benefit of 507 over the new element for users, and despite being _less characters_ the syntax is going to be completely alien to developers. |
| 16:31 | <annevk> | Wilto: conventions are not everything |
| 16:32 | <annevk> | Wilto: simplicity counts |
| 16:32 | <odinho> | Wilto: I can't speak for others, but I've been following the CG. -- And seeing the proposals both hober and hixie came with they seem to have seen it as well. |
| 16:32 | <Wilto> | Brevity and simplicity are not the same thing. |
| 16:32 | <Wilto> | Where have they been in the conversations, then? |
| 16:32 | <annevk> | Wilto: there's a lot more parameters for video/audio unfortunately that make them more complex, though in retrospect I'm not sure <source> was such a good idea |
| 16:32 | <othermaciej> | the syntax is pretty similar to proposed CSS image-set, which is implemented in WebKit and has been used by developers without undue confusion |
| 16:32 | <Wilto> | I can’t help feeling like the CG was a little sandbox for the developers to play in while the decisions were made without us, seeing the progress presented here. |
| 16:33 | <odinho> | Yes, it's basically image-set ported to html. |
| 16:33 | <annevk> | Wilto: I didn't know there was a CG |
| 16:33 | <paul_irish> | just to provide context, he's corralled and led a group of the best mobile web developers, created a CG, isolated a solution (from many), fought for and won consensus within the group, wrote a draft spec and proposed it. Basically he's done the thing standards folks really want "authors" to do. Which is why this this feels so defeating. |
| 16:33 | <othermaciej> | I don't even know if there is a decision |
| 16:33 | <othermaciej> | I'm certainly not the decider |
| 16:34 | <othermaciej> | I just gave some input, and I'm explaining to you guys now what I think the tradeoffs among different options are |
| 16:34 | <Wilto> | Thanks, paul_irish. I’m tryin’, at least. |
| 16:34 | <othermaciej> | I did not know there was a CG for this specific topic, nor was I aware that it had produced a draft spec |
| 16:34 | <annevk> | paul_irish: not sure we'd want people to create their own groups, not sure there has been a decision either |
| 16:34 | <othermaciej> | pointers? |
| 16:35 | <Wilto> | othermaciej: Admittedly, this is my effort at winging a spec. I am no spec author. https://github.com/Wilto/respimg |
| 16:35 | <Wilto> | Just a way of getting all the details in one place. |
| 16:35 | <Wilto> | The community group is here. http://www.w3.org/community/respimg/ |
| 16:36 | <Wilto> | If you're in the mood for prose, some of the details leading to the group's creation and efforts are detailed at http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ and http://www.netmagazine.com/features/state-responsive-images |
| 16:36 | <Wilto> | Interest from the public crashed the CG database servers when the group was formed. |
| 16:37 | <othermaciej> | Wilto: it seems like a neat proposal, one thing I am not clear on is the specific algorithm to be used for selecting among the <source> elements |
| 16:37 | <othermaciej> | last one whose media query matches wins? |
| 16:37 | <Wilto> | If no one’s heard of my group -- considering how big my soapbox is -- it sure sucks to be your average developer with something to say. |
| 16:38 | <othermaciej> | was it announced to any of the existing groups working on standardization of HTML? |
| 16:38 | <annevk> | well it's pretty easy, submit proposals to whatwg⊙wo |
| 16:38 | <divya> | yes it was. |
| 16:38 | <Wilto> | I did. |
| 16:38 | <annevk> | alright |
| 16:38 | <divya> | annevk: it was submitted |
| 16:38 | <odinho> | Wilto: As I said, I've followed it after I saw it on whatwg. |
| 16:38 | <annevk> | then I'm pretty sure it was considered |
| 16:38 | <divya> | huh |
| 16:38 | <divya> | and then dismissed? |
| 16:38 | <Wilto> | Yeah. No accusations here, odinho. I’m just discouraged, here. |
| 16:39 | <Wilto> | annevk: An email would’ve been nice. |
| 16:39 | <annevk> | divya: well no, I assume Hixie will write one of his emails replying to everyone who gave input on the topic |
| 16:39 | <odinho> | AFAIK he started on that yesterday. |
| 16:39 | <odinho> | Wilto: The email is not yet sent. |
| 16:39 | <othermaciej> | was rasping mentioned on whatwg@ prior to May 10th? |
| 16:39 | <othermaciej> | er, "respimg" |
| 16:39 | <othermaciej> | I can't find any mention |
| 16:39 | <annevk> | Wilto: if you emailed the list you'll get one :) |
| 16:40 | <Wilto> | annevk: Hixie responded that CSS solved this problem, and then I didn’t hear from him further. |
| 16:40 | <Wilto> | Look, my tone isn't great here, and for that I genuinely apologize. |
| 16:40 | <annevk> | Wilto: I get the frustration :) |
| 16:40 | <othermaciej> | and I can't find any mentions at all on public-html |
| 16:40 | <Wilto> | But, man, this is kind of a beatdown. |
| 16:40 | <odinho> | hober heard that hixie was writing a respimg reply, -- and so he remembered he had an unsent email about it, and sent that. |
| 16:40 | <divya> | othermaciej: http://www.w3.org/Search/Mail/Public/search?type-index=public-html&index-type=t&keywords=picture+element |
| 16:41 | <Wilto> | Interestingly, othermaciej, it first came up in 2007 and a few times since. One sec; I have previous discussion documented. |
| 16:41 | <divya> | othermaciej: it is under 'prior art and discussion' |
| 16:41 | <Wilto> | Actually, yeah, there are a few links at https://github.com/Wilto/respimg#5-prior-discussion |
| 16:42 | <othermaciej> | none of those emails seem to mention the respimg community group |
| 16:42 | <othermaciej> | that's the bit I'm wondering about |
| 16:42 | <annevk> | Wilto: anyway, I suggest giving it another day / two days until Hixie posted his rationale |
| 16:42 | <Wilto> | This… seems fundamentally flawed. |
| 16:42 | <othermaciej> | you can't expect people to be aware of your CG's discussions if you didn't tell them about the CG |
| 16:42 | <annevk> | Wilto: and if you disagree with his arguments say so, this is not exactly set it stone |
| 16:42 | <annevk> | in* |
| 16:43 | <Wilto> | othermaciej: It was; I can dig through the list for mentions. I mostly documented discussion on the threads prior to the CG. |
| 16:43 | <othermaciej> | and if you want to make a spec that might get implemented in browsers, it's to your advantage to make sure at least some browser implementors participate in your group |
| 16:43 | <Wilto> | othermaciej: They have. |
| 16:44 | <necolas> | othermaciej: the respimg CG took down the whole server, such was the initial interest. i think people knew it was there |
| 16:44 | <divya> | othermaciej: i dont even know anymore. W3C says create community group, get partners in. |
| 16:44 | <annevk> | necolas: W3C systems team might have known, I never heard about that :) |
| 16:44 | <divya> | so it was done. |
| 16:44 | <divya> | so now what then. |
| 16:44 | <necolas> | annevk: that's surprising |
| 16:44 | <divya> | everything that was asked of developers was done |
| 16:45 | <divya> | especially with the superhuman effort of Wilto to put them all together. |
| 16:45 | <necolas> | annevk: considering the massive interest in the dev community |
| 16:45 | <Wilto> | Yeah. Like divya says: I wasn’t given a process. I was given a Wordpress blog and a hearty "good luck." |
| 16:45 | <othermaciej> | I can't find any mention of the string "respimg" in my public-html folder, and only one mention on May 10th (today) in my whatwg folder |
| 16:45 | <divya> | othermaciej: so we need to alert public-html with respimg? |
| 16:45 | <Wilto> | Yeah, is that what it comes down to? |
| 16:46 | <othermaciej> | well the fact that you didn't is probably the reason many folks working on the html spec itself have never heard of it before |
| 16:46 | <Wilto> | In fairness, at no point did I see it fit to say "our community group still exists." |
| 16:46 | <othermaciej> | if they had heard of it, they might have participated |
| 16:46 | <divya> | othermaciej: who *are* working on the spec? |
| 16:46 | <divya> | all we know is hixie |
| 16:46 | <annevk> | CGs work if you have all the relevant stakeholders there; just having a CG and a bunch of people participating does not necessarily create a standard |
| 16:46 | <necolas> | othermaciej: the problem is that the WG's dont engage the general developer community, even when they set up CG blogs for them |
| 16:46 | <divya> | how are we supposed to know who all to work? |
| 16:46 | <divya> | Who *are* the stackholders. |
| 16:46 | <annevk> | and if you want to change HTML, it goes via the WHATWG |
| 16:47 | <Wilto> | othermaciej: The point of the community groups is to connect developers with those involved standards process. |
| 16:47 | <divya> | this spec was shown to implementors in Opera, Google |
| 16:47 | <Wilto> | in the* |
| 16:47 | <divya> | and whoever showed interest. |
| 16:47 | <divya> | (i am using the word spec loosely) |
| 16:47 | <Wilto> | No arguments there, divya. It’s a... "Pseudospec." |
| 16:47 | <Wilto> | Just key implementor details in one semi-formal place. |
| 16:47 | <divya> | at NO POINT did anyone mention pinging whatwg about the existence of the CG |
| 16:47 | <divya> | or anything similar. |
| 16:48 | <annevk> | divya: not sure who you talked to then... |
| 16:48 | <annevk> | divya: but you can't extend HTML in a vacuum |
| 16:48 | <divya> | annevk: i sent it to the opera core mailing list |
| 16:48 | <necolas> | right back at ya :P |
| 16:48 | <divya> | zcorpan even commented |
| 16:48 | <annevk> | necolas: sure man, but 90 people is less than 1500 |
| 16:48 | <Wilto> | I sent it to Chrome’s standards list, as well. |
| 16:48 | <necolas> | there's obviously been a communication breakdown |
| 16:48 | <divya> | yeah lets just move on from this. |
| 16:49 | <necolas> | hopefully everyone can learn lessons from it |
| 16:49 | <divya> | the point is now what. |
| 16:49 | <Wilto> | Agreed. |
| 16:49 | <annevk> | I recommend emailing the proposal to the WHATWG list at least |
| 16:49 | <necolas> | because im sure most of the whatwg actually want to have happy, engaged developers involved |
| 16:49 | <othermaciej> | independent of the communications breakdown, it seems like there are two useful things: |
| 16:49 | <necolas> | and developers dont want to feel pushed out and told off for not doing things as they should be done |
| 16:49 | <othermaciej> | 1) send the proposal (not just a link to the CG) to whatwg@ |
| 16:50 | <othermaciej> | 2) send a list of use cases it's meant to address |
| 16:50 | <othermaciej> | 3) if Hixie puts something in the spec that does not meet all your use cases, point out which ones are not addressed |
| 16:50 | <othermaciej> | in general you will have a better time if you focus more on use cases and don't sweat it too much if the final syntax is not exactly what you wished for |
| 16:51 | <annevk> | necolas: agreed, if there's anything we can improve in http://wiki.whatwg.org/wiki/FAQ that would be useful to know |
| 16:51 | <annevk> | I have to go now unfortunately |
| 16:51 | <othermaciej> | I guess that was 3 things |
| 16:51 | <Wilto> | I genuinely don’t care about the pattern itself, beyond the fact that—of the many markup patterns we discussed—this is the one for which most developers involved voiced a preference. |
| 16:51 | <Wilto> | As long as the use cases are, as you said, met. |
| 16:52 | <Wilto> | 3 makes me very uneasy, however. |
| 16:52 | <othermaciej> | I can see that <picture> can in theory do lots of things that imgset can't, what I'm wondering about is which of those things are specifically important to web developers for particular use cases |
| 16:52 | <divya> | Wilto: i think the least we can do is #1 and #2 |
| 16:52 | <Wilto> | I assumed that, as someone who has spent a year discussing this with many developers and browser representatives, there would be a general overtone of “oh, good, welcome to the discussion—you’ll likely have insight here." |
| 16:52 | <divya> | lets worry about #3 when it comes to that. |
| 16:53 | <Wilto> | It sounds more like I have a chance to say "oh hey waitasec" after it has been specced. |
| 16:53 | <Wilto> | Guess so, yeah. |
| 16:53 | <othermaciej> | Wilto: you are definitely welcome to discuss! |
| 16:53 | <tantek> | othermaciej - perhaps every new CG created should be announced to whatwg? |
| 16:54 | <othermaciej> | I suggest that you put your list of use cases front and center |
| 16:54 | <othermaciej> | tantek: well, if it is planning to do something HTML-related then yes |
| 16:54 | <Wilto> | Again, guys, I genuinely apologize for my tone here. |
| 16:54 | <Wilto> | I've just owned this topic for a very long time. It's... Not un-stressful. |
| 16:55 | <tantek> | othermaciej - I think the problem with that is that CG are started to solve a problem / use-case, and that "do something HTML-related" is a specific type of solution that may or may not be clear from the outset. |
| 16:55 | <tantek> | hence my suggestion that might as well announce them all to whatwg, since they *might* do something HTML-related |
| 16:55 | <necolas> | Wilto: the dev community appreciates your massive efforts to bridge the gap |
| 16:56 | <divya> | well we certainly do Wilto. |
| 16:56 | <Wilto> | Thanks, guys. |
| 16:57 | tantek | reiterates his position that email lists tend to function more as support forums in practice than for any actual development (which has shifted in practice to IRC + wikis, or email just for snapshot announcements of proposals) |
| 16:58 | <othermaciej> | tantek: good point - but they might also do something Web API related or CSS related (or perhaps in rare cases SVG-related) |
| 16:58 | <tantek> | The whatwg list only seems to "work" because Hixie uses it as his personal inbox. |
| 16:59 | <tantek> | othermaciej - those groups seem more willing to accept outside consensus as a starting point for discussion than whatwg. |
| 16:59 | <othermaciej> | I think different people are comfortable with different communication modes |
| 17:00 | <tantek> | othermaciej - differences in communication comfort doesn't dispute my conclusion about email = support forum in practice. |
| 17:00 | <shepazu> | tantek: for reference, the SVG WG works via email and telcon more than IRC |
| 17:01 | <tantek> | cont'd re other groups vs. whatwg: whatwg appears have to have developed more of an NIH type culture (as evidenced by the responsive images example). |
| 17:01 | <tantek> | shepazu, I can see "has worked", but I'm not convinced that occurs much anymore. |
| 17:02 | <tantek> | even CSS has switched more to many things being quickly hashed out in IRC first |
| 17:02 | <othermaciej> | I don't know if this is an example of NIH, people were just genuinely other ware of the other proposal and other venue |
| 17:02 | <othermaciej> | might have sent the discussion in a different direction had they known |
| 17:02 | <shepazu> | tantek: I'm not trying to convince you, I'm telling you how the SVG WG works, and you can choose to believe otherwise if it fits your model better… Audio WG is the same way, btw |
| 17:02 | <othermaciej> | otoh whatwg seems to only consider proposals that have actually been implemented as particularly strong precedent, not just ones that have been discussed |
| 17:03 | <tantek> | othermaciej - but that doesn't matter, once made aware that there has already been a lot of work done, it's worth evaluating that rather than a few day brainstorm in progress. |
| 17:03 | <tantek> | othermaciej - that has the weakness of preferring browser implementers over developers / authorability. |
| 17:03 | <tantek> | which is an inversion of the the respective HTML design principles' community priorities. |
| 17:04 | <othermaciej> | tantek: I don't think anyone has told the proponents of the other proposal to go home or ignored their input, the most recent actual discussion about this was prior to knowing about their work |
| 17:04 | <othermaciej> | at least, that applies to any discussions I've been involved with |
| 17:05 | <tantek> | from Wilto's apparent frustration, it sounds like he feels like he is being effectively ignored. correct me if I'm wrong Wilto. |
| 17:05 | <othermaciej> | tantek: the design principle priorities are about who benefits, not who is most qualified to decide - just as asking users what they want isn't usually the best way to do HI design, asking clients what they want isn't necessarily the best way to do API design |
| 17:05 | <Wilto> | Speaking as a developer completely new to any "pitching standards" processes, I assumed there was an inherent connection between the CGs and those involved in this process. |
| 17:05 | <tantek> | othermaciej - sure |
| 17:05 | <othermaciej> | I think Wilto expected that everyone should have already known about his CG and taken it as precedent |
| 17:05 | <Wilto> | I didn't think it was necessary — or even appropriate — to point it out on several occasions. |
| 17:06 | <tantek> | Wilto, that being said, nothing is stopping you or the CG from bringing your proposal directly to browser implementers (e.g. filing bugs in their respective bug databases) |
| 17:06 | <Wilto> | tantek: I have, yeah. |
| 17:06 | <tantek> | if you think you have a solid consensus proposal |
| 17:06 | <tantek> | if the browser implementers implement it, then whatwg will likely spec it as implemented. |
| 17:07 | <othermaciej> | fwiw, at Apple we discussed the tradeoffs between a <picture>-like design vs the srcset-style design and thought the latter was better |
| 17:07 | <tantek> | so that's another path that's always available, you don't have to coordinate with whatwg (though you're likely to get a better spec/technology/adoption if you do) |
| 17:07 | <tantek> | othermaciej, good to know |
| 17:07 | <othermaciej> | in large part due to experience with media queries being too verbose for the related use cases in CSS |
| 17:07 | <Wilto> | I mean… I _want_ to coordinate with the WHATWG. |
| 17:08 | <othermaciej> | clients we talked to really wanted something more concise, thus the CSS image-set() proposal |
| 17:08 | <tantek> | Wilto, cool, then do you understand what is requested of you re: documenting use-cases? |
| 17:08 | <othermaciej> | the feedback we have gotten is that it's more usable |
| 17:08 | <tantek> | othermaciej - it sounds like the question is not just one of syntax/usability, but does it solve the use-cases. |
| 17:09 | <tantek> | thus I agree that some documenting of use-cases, e.g. on a wiki, is an important next step |
| 17:09 | <othermaciej> | I agree |
| 17:09 | <annevk> | tantek: fwiw, announcing all CGs on the WHATWG list is bad for S/N |
| 17:09 | <tantek> | annevk - are there that many CGs? |
| 17:09 | <Wilto> | tantek: I believe so, yes. |
| 17:09 | <annevk> | tantek: yes |
| 17:09 | <tantek> | and if CGs don't affect the web platform, then what are they doing at W3C? |
| 17:09 | <Wilto> | And I do appreciate the guidance in here, sincerely. |
| 17:10 | <othermaciej> | there are a huge number of CGs and there are indeed ones that do not affect the Web platform |
| 17:10 | <othermaciej> | Apple folks' opinion on <picture> vs srcset would probably be different if we knew <picture> handled some important use cases that can't practically be done w/ srcset |
| 17:11 | <Wilto> | othermaciej: Is Apple comfortable with implementing a "look-ahead" of sorts on the img tag? |
| 17:12 | <timeless> | odinho / hober : if you guys have corrections |
| 17:12 | <othermaciej> | Wilto: I'm not totally sure what you mean by "look-ahead" |
| 17:12 | <timeless> | i'm working on webapps minutes now |
| 17:12 | <Wilto> | The word I've gotten from a few WebKit devs is that it wouldn't fly; the src of the img will be prefetched in any case, leading to a redundant request. |
| 17:12 | <Wilto> | Which would very much defeat the purpose of any new markup pattern. I mean, otherwise, we'd just script something. |
| 17:14 | <Wilto> | Or use CSS pattern to swap the source, using some of the proposals out there already. Namely: http://www.w3.org/TR/css3-values/#attr |
| 17:15 | <othermaciej> | Wilto: I'm still not sure what you mean by look-ahead |
| 17:16 | <othermaciej> | I think in either the picture-style solution or the srcset-style solution, we'd only load the selected image |
| 17:16 | <Wilto> | That's likely not the right term. I mean... In terms of prefetching, would the browser be able to say "this is an image. Before fetching the src, I should see if there are alternate sources specified." |
| 17:16 | <Wilto> | On paper, I'd think "yeah, of course it can." |
| 17:17 | <othermaciej> | I believe it is possible with either the srcset syntax or the <picture> syntax, with a browser-native implementation at least |
| 17:17 | <Wilto> | If so, it would have to prefetch an appropriate source. I don't know the internals there; would the client information be available at that time? Would they want to kick in that logic during the prefetching process? |
| 17:17 | <timeless> | annevk: gah. i'm ~500 conversations behind on www-style |
| 17:18 | <Wilto> | Hm. See, we kept pitching ideas based on modifying img, and they were all promptly shut down for that reason. |
| 17:19 | <Wilto> | A new element would afford UAs an opportunity to build in more advanced logic. They... generally do not seem eager to bolt things onto <img>, whether that's by choice or necessity. |
| 17:19 | <othermaciej> | prefetch would have to be smarter to avoid accidentally prefetching the src |
| 17:20 | <othermaciej> | and prefetching an image based on width selection may well be impossible to do correctly |
| 17:20 | <Wilto> | Right. Which, on paper, seems fine. I don't know though; I have to go on the word of the browser devs we've been speaking to. |
| 17:20 | <othermaciej> | but prefetching the right one based on resolution is practical |
| 17:20 | <Wilto> | I haven't heard anything indicating that width-based sources would be an issue. |
| 17:21 | <webben> | Has anyone proposed a @defer attribute or something for iframe (would be useful for implementing non-blocking ads, widgets, videos etc)? |
| 17:24 | <othermaciej> | width-based sources (at least as proposed in srcset) depend on the available width, which is not known until layout time, so can't be done at prefetch time |
| 17:25 | <Wilto> | Yeah, see, that's what I was worried about. |
| 17:26 | <Wilto> | We'd effectively be saying "if this <img> has an alternate source, disable prefetching on it." I'm certain that won't fly. |
| 17:26 | <othermaciej> | so you could choose to do no preloading at all in that case |
| 17:26 | <othermaciej> | not really an issue for the 1x vs 2x resolution use case though |
| 17:26 | <Wilto> | No one has voiced the same concerns about <picture>, however. I assume they're afforded more flexibility in implementation with a blank canvas. |
| 17:27 | <othermaciej> | I do not know if it is possible to evaluate arbitrary media queries at preloading time |
| 17:27 | <Wilto> | (we tried <canvas> for workarounds, too. Ba-dum tss.) |
| 17:33 | <timeless> | anyone from the webapps f2f around to help me? |
| 17:38 | <tantek> | timeless what's up? |
| 18:11 | <dglazkov> | rafaelw_: I'd suggest starting a new thread with the new-best solution and getting ayes/nays on it |
| 18:12 | <rafaelw_> | ok |
| 18:26 | <timeless> | tantek: trying to fix up the minutes |
| 18:30 | <tantek> | timeless ok |
| 18:55 | timeless | sighs |
| 18:55 | <timeless> | Chrome is such a crappy browser for simple <find-forward> tasks |
| 18:55 | <timeless> | Obviously having scrolled to an anchor using <find>, i want to search from the _top_ of the document when i find again |
| 18:56 | <timeless> | and i obviously want to search letter at a time |
| 18:58 | <timeless> | odinho: ok... |
| 18:58 | <timeless> | odinho: read through everything |
| 18:58 | <timeless> | ... but when we send new comments |
| 18:58 | <timeless> | ... it's because we got to a new point |
| 18:58 | <timeless> | odinho: so far it's things that aren't really defined |
| 18:58 | <timeless> | ... and nitpicking, making things easier to read |
| 18:58 | <timeless> | hober: i hope the two of you are ok w/ that correction |
| 19:03 | timeless | goes back to looking at the minutes and the minute scripts |
| 19:26 | <Ms2ger> | gavinc, you may be interested in the compromise webperf has for its DOM reference: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html#DOM3Core |
| 19:32 | <timeless> | Ms2ger: what's w/ the random link/no-link behavior? |
| 19:33 | <timeless> | Available at http://www.ietf.org/rfc/rfc2119.txt [link] |
| 19:33 | <timeless> | The latest version of DOM4 is available at http://www.w3.org/TR/dom/ [notlink]. |
| 19:33 | <timeless> | This version of the ECMAScript Language is available from http://www.ecma-international.org/publications/standards/Ecma-262.htm [notlink]. |
| 19:33 | <Ms2ger> | "Incompetence" |
| 19:33 | <timeless> | aha |
| 19:33 | <timeless> | well, i'm happy |
| 19:34 | <timeless> | my scripts can now distinguish Paul_Cotton form Paul_Kinlan |
| 19:34 | <timeless> | at least, if Paul_Kinlan speaks... |
| 19:34 | <timeless> | (the script is still pretty stupid in the case when paul kinlan doesn't speak) |
| 19:34 | <timeless> | s/form/from/ |
| 19:47 | <dglazkov> | timeless: file a bug? I'll cc finnur, who can fix it |
| 19:47 | <eighty4> | anyone happen to know if you can redefine how contenteditable inserts <br>s and <div>s and so on? |
| 19:52 | <Ms2ger> | I'm sure AryehGregor does |
| 19:57 | <gavinc> | Ms2ger: thanks |
| 19:57 | <Ms2ger> | Np |
| 20:11 | <timeless> | dglazkov: that'd require me to find the bug database and credentials |
| 20:11 | <timeless> | sorry, my top priority right now is minutes from last week |
| 20:16 | <timeless> | tantek: <dt id="T21-51-45">21:51:45 [chaals]</dt><dd>tantek: deoms are awesome. scope is broader than I ahd understood. How broad is the scope intended to be?</dd> |
| 20:16 | <timeless> | i presume "deoms" should be "DCOM" ? |
| 20:17 | timeless | isn't sure and hasn't gotten around to running the results through a spell-checker |
| 20:18 | <tantek> | no deoms is a typo transposition of demos |
| 20:18 | <timeless> | ok |
| 20:18 | <tantek> | but sure, related topics mentioned were DCOM, DSOM etc., I think that was earlier |
| 20:19 | <tantek> | and CORBA for that matter |
| 20:19 | timeless | nods |
| 20:19 | <timeless> | lemme send this thing through a spell checker |
| 20:21 | <timeless> | kam = kamos = komoroske = Alex_Komoroske:, right? |
| 20:21 | <tantek> | https://twitter.com/jackrusher/status/199851560665235457 |
| 20:23 | <tantek> | except that I don't think the #webintents folks know of CORBA - they're simply reinventing it (as well as OpenDoc/OLE) by walking down the same paths. it's like some odd 20 year generational cycle. |
| 20:24 | <timeless> | well |
| 20:24 | <timeless> | i'm vaguely involved in intents |
| 20:24 | <timeless> | and i've dealt w/ corba and ole, and i have memories of opendoc |
| 20:25 | <timeless> | what prevents someone from claiming that the embeddable Gmaps apis violate OpenDoc/OLE patents? |
| 20:25 | <tantek> | timeless - you seem to be vaguely involved with many web things :) |
| 20:25 | <timeless> | yes |
| 20:26 | <timeless> | OT: did you get around to rebooting your mac? |
| 20:26 | <tantek> | I'm not very familiar with embeddable Gmaps APIs - you'd have to talk to someone who understands both technologies |
| 20:26 | timeless | just upgraded PlayBook and phone os's |
| 20:26 | <tantek> | no |
| 20:26 | <tantek> | I don't reboot very often. |
| 20:26 | <timeless> | well... to the end user, you end up w/ a google map inside someone else's web page |
| 20:26 | <timeless> | you can interact w/ the google map pretty much the way you would if it weren't embedded |
| 20:26 | <timeless> | which is more or less what OpenDoc/OLE allow |
| 20:27 | <timeless> | Intents most of the time will not actually give you that |
| 20:27 | <tantek> | problem with OpenDoc/OLE is it was a huge set of technologies |
| 20:27 | <tantek> | some of which was patented |
| 20:27 | <timeless> | it's mostly just giving you a function that can return a value |
| 20:27 | <tantek> | so you can't prove anything by the negative |
| 20:27 | <timeless> | it's closer to CORBA than OLE/OpenDoc |
| 20:28 | <timeless> | hrm |
| 20:28 | <timeless> | put slightly differently |
| 20:28 | <tantek> | timeless - from the WebApps f2f there is no "mostly just" with webintents. |
| 20:28 | <tantek> | it's an ever growing scope |
| 20:28 | <tantek> | I wish you luck with attempting to limit it |
| 20:28 | <timeless> | are the OLE/OpenDoc patents older than the MPEG1 patents? :) |
| 20:28 | <tantek> | I've already decided on the specific focus I'm solving with web actions. |
| 20:29 | <tantek> | timeless - if you're curious, you can do your own patent search. |
| 20:29 | <tantek> | I'm not familiar with MPEG1 patents (nor do I have any interest in being) |
| 20:29 | <timeless> | i'm pretty sure my lawyers would yell at me :) |
| 20:29 | <tantek> | exactly |
| 20:29 | <tantek> | so it's futile to attempt to reason by the negative |
| 20:29 | timeless | sighs |
| 20:29 | <timeless> | well, i'm not trying to really reason |
| 20:29 | <timeless> | just paint a broad stroke |
| 20:30 | <timeless> | i have a feeling that ole/opendoc could be older than mpeg1 |
| 20:30 | <timeless> | and we've sort of reached a point where mpeg1 patents were offering to expire |
| 20:45 | <Velmont> | timeless: Thanks for fixing that :) |
| 20:47 | <rniwa> | the whole discussion about arabizi was funny.... |
| 21:34 | <timeless> | Velmont: thanks for pointing it out |
| 21:34 | <timeless> | Testing |
| 21:34 | <timeless> | rniwa: I like to write tests |
| 21:34 | <timeless> | ... if we have a tool that could go through the tests |
| 21:34 | <timeless> | <inserted> schepers: |
| 21:34 | <timeless> | rniwa: the CSS Tool called "Shepard" (by plinns) |
| 21:34 | <timeless> | -- help? |
| 21:34 | <shepazu> | huh? |
| 21:35 | <timeless> | chaals inserted "shepazu:" before "Shepard" |
| 21:35 | <timeless> | i'm not sure why |
| 21:35 | <timeless> | was he trying to say that you were speaking? |
| 21:35 | <timeless> | i.e. did you say "the CSS Tool called" ? |
| 21:36 | timeless | decides that shepazu probably did say that (and not rniwa) |
| 21:37 | <shepazu> | timeless: yes, I did mention Shepard |
| 21:37 | <timeless> | ok, great, thanks |
| 21:37 | <timeless> | note that the final minutes won't say schpers |
| 21:38 | <timeless> | it says that so i can test a scribe speaker-present tool |
| 21:49 | <paul_irish> | shepazu: where is this tool? i'm interested. |
| 21:50 | <paul_irish> | http://test.csswg.org/shepherd/ |
| 21:50 | <paul_irish> | http://wiki.csswg.org/test/css2.1/contribute |
| 21:53 | <shepazu> | paul_irish: it's where you just pointed |
| 21:53 | <shepazu> | :| |
| 21:53 | <paul_irish> | :) |
| 21:54 | <timeless> | ok, i've sent off minutes for webapps |
| 21:54 | <timeless> | i'll try to deal w/ html tomorrow |
| 21:54 | <timeless> | maybe. i have other things to worry about tomorrow |
| 21:54 | <timeless> | they're in www-archive for now |
| 21:55 | <timeless> | if people ( Velmont, shepazu , odinho , anne, ...) could review them |
| 21:55 | <timeless> | i'd appreciate it |
| 22:04 | <Velmont> | timeless: Velmont === odinho |
| 22:06 | <rniwa> | timeless: sorry, i was away from keyboard |
| 22:06 | <rniwa> | timeless: did you need me for something? |
| 22:37 | <cbright6062> | sigh. the busyness of work. |
| 22:56 | <smaug____> | seriously, linking to dart code for use cases for the web... |
| 23:19 | <tabatkins> | smaug____: Dart is almost JS. Seems legit. |
| 23:20 | <smaug____> | Dart code is like Java |
| 23:20 | <smaug____> | as much webby |
| 23:35 | <arv> | smaug____: The Dart library uses the same DOM APIs as JS. |
| 23:36 | <smaug____> | arv: the API is quite different |
| 23:36 | <smaug____> | and Java uses the same APIs too |
| 23:36 | <arv> | smaug____: it is irrelevant which language someone uses when the underlying capabilities is just DOM4 |
| 23:36 | <arv> | smaug____: yes, and java has the same issue regarding context less parsing |
| 23:36 | <smaug____> | actually, there isn't any webidl spec for Dart |
| 23:37 | <arv> | smaug____: so? |
| 23:37 | <smaug____> | and my main point is that it is very un-webby and silly to demonstrate anything on a research language and not using JS |
| 23:37 | <arv> | smaug____: there isn't one for cs eitehr |
| 23:37 | <smaug____> | arv: where is the webidl spec for Dart? |
| 23:38 | <arv> | smaug____: see above. the langiuage is irrelevant |
| 23:38 | <smaug____> | ok. I use Perl next time in my examples :/ |
| 23:39 | <arv> | sgtm |
