| 06:08 | <AryehGregor> | <eighty4> anyone happen to know if you can redefine how contenteditable inserts <br>s and <div>s and so on? <-- What behavior do you want? |
| 06:17 | <AryehGregor> | eighty4, currently IE/Opera wrap everything in <p> on Enter, Firefox inserts <br>, WebKit uses <div> for line breaks but very recently added support to opt in to <p> instead (defaultparagraphseparator command). I'm currently working on a patch for Gecko to more closely match IE/Opera behavior, which is what the editing spec requires. |
| 06:17 | <AryehGregor> | So once that patch lands, the most recent version of everything will do <p> (at least if you opt in with defaultparagraphseparator, for WebKit). |
| 06:18 | <AryehGregor> | Although the exact places they create the separator will still vary -- e.g., "foo\nbar" in an empty editable div should create "<p>foo</p><p>bar</p>" per spec, but in WebKit probably produces "foo<p>bar</p>", browsers might leave useless trailing <br>'s, etc. |
| 06:18 | <AryehGregor> | Any questions? :) |
| 06:19 | <AryehGregor> | (there are a lot more details here, FWIW, I'm just talking about the most basic case; what happens if you hit Enter in an <li>, <h#>, etc. is a different story) |
| 07:33 | <jgraham> | zcorpan: Compile errors don't have a stack either |
| 07:36 | <zcorpan> | jgraham: indeed |
| 07:36 | <zcorpan> | jgraham: but they have a column number |
| 07:39 | <jgraham> | Weren't you proposing passing in both? |
| 07:41 | <zcorpan> | yes. but he suggested dropping column and replacing it with Error |
| 07:41 | <zcorpan> | and putting column on Error |
| 07:41 | hober | catches up on the backlog |
| 07:42 | <hober> | not being in pacific time can be inconvenient |
| 07:43 | <jgraham> | zcorpan: That doesn't sound very compatible |
| 07:44 | <zcorpan> | jgraham: column is a new thing, though |
| 07:44 | <jgraham> | hober: You are living in the silicon valley bubble :p |
| 07:45 | <hober> | :) |
| 07:45 | <jgraham> | zcorpan: No one supports it? |
| 07:45 | <zcorpan> | right |
| 07:45 | <jgraham> | I see |
| 07:45 | <zcorpan> | maybe ie10, dunno |
| 07:45 | <zcorpan> | ms proposed it |
| 07:46 | <jgraham> | Well I think passing in the error object somewhere (when it exists) is a good idea |
| 07:46 | <hober> | Wilto othermaciej tantek et al.: sorry I missed your discussion last night. |
| 07:46 | <hober> | i'll write up my thoughts on <picture> and why i prefer <img srcset> for the Retina/non-Retina use case soon, but i'm at the css f2f and don't have the time for it right now |
| 07:47 | <hober> | [i had the time to "write up" <img srcset> because i had already written the email, just hadn't sent it. :)] |
| 07:48 | <hober> | Wilto: I was aware of the CG and the various conversations online that preceded it (on ALA, the etherpad, the june 2007 thread on public-html, etc.) |
| 07:48 | <zcorpan> | i prefer an attribute because it makes the processing much simpler. <source> is hard |
| 07:49 | <gsnedders> | zcorpan: Is there any reason why we can't just pass in the exception value? |
| 07:49 | <hober> | Wilto: and reviewing all of that most definitely influenced the design of my proposal |
| 07:49 | <gsnedders> | I mean, we can always create SyntaxError objects aside from the eval case |
| 07:49 | <zcorpan> | gsnedders: no reason, i'm just trying to figure out what information he wants |
| 07:50 | <hober> | Wilto: <img srcset> isn't a panacea; it's intended to solve some of the problems identified under the umbrella term "responsive images" |
| 07:50 | <zcorpan> | gsnedders: oh you mean for compile errors? |
| 07:50 | <zcorpan> | gsnedders: yeah we could create an exception object for that case |
| 07:50 | <gsnedders> | zcorpan: Nah, I mean in general, and suggesting how we handle the compile-error case |
| 07:50 | <hober> | zcorpan: indeed |
| 07:52 | <hober> | Wilto: anyway, i'm sorry if you interpreted my email as ignoring the hard work that the cg has done |
| 07:54 | <hober> | Wilto: what happened was quite the opposite; i went over many of the discussions (both in the cg, on the whatwg and html wg mailing lists, and in the wider community prior to the cg's formation) while working on the problem |
| 08:41 | <smaug____> | hmm, whether or not un-prefix MutationObserver now |
| 08:41 | <smaug____> | perhaps I should test the implementations some more |
| 08:41 | <annevk> | if you unprefix it now and there's edge case bugs you should still have time to fix them |
| 08:41 | <smaug____> | or anyone else willing to test the implementations? ;) |
| 08:42 | <smaug____> | annevk: true |
| 08:42 | <annevk> | it's more about whether you trust the general design enough I guess |
| 08:42 | <zcorpan> | UNPREFIX ALL THE THINGS! |
| 08:42 | <annevk> | but given that there's now blog posts advocating people to use it, I'd prefer we just went with it |
| 08:42 | <smaug____> | it is perfect design. design by me (and others) ;) |
| 08:43 | <Ms2ger> | Hah |
| 08:43 | <Ms2ger> | It's in a spec, surely it isn't perfect |
| 08:43 | <smaug____> | that is true. should we take it out from the spec :) |
| 08:43 | <jgraham> | Didn't the link to "spec" in the blogpost go to an email? |
| 08:44 | <annevk> | yeah so no problems there |
| 08:44 | <smaug____> | jgraham: in mozilla hacks= |
| 08:44 | <smaug____> | s/=/?/ |
| 08:44 | <annevk> | yup |
| 08:44 | <smaug____> | jgraham: I posted a comment about that |
| 08:44 | <smaug____> | with the right link |
| 08:44 | <jgraham> | Oh, I saw it on planet mozilla, so no comments |
| 08:45 | <smaug____> | I just posted my comment |
| 08:45 | <smaug____> | annevk: jgraham: but in general Opera doesn't see anything hugely wrong with the API ? |
| 08:45 | smaug____ | should ask MS |
| 08:46 | <Ms2ger> | Land it |
| 08:46 | <Ms2ger> | Oh, other MS |
| 08:49 | <jgraham> | smaug____: I haven't studied it in detail. I thought annevk was following it more closely. But I asked some of our developers and I think their opinion was roughly "it can't be worse than mutation events" mixed with a little "we are probably stuck with mutation events, so is having an extra API here a good idea" |
| 08:49 | <jgraham> | +? |
| 08:50 | <annevk> | yeah |
| 08:50 | <annevk> | though also combined with if we can get rid of mutation events that'd be really awesome... |
| 08:51 | <smaug____> | jgraham: well, we at least should try to get rid of mutation events |
| 08:51 | <annevk> | I'd hate having to define them in DOM |
| 08:51 | <smaug____> | MutationObserver is 5-10 faster than MutationEvents (both in Gecko and Webkit), and it is 'safe' |
| 08:52 | <jgraham> | Well sure, if we can kill mutation events there will be rejoicing in the streets of Oslo |
| 08:52 | <smaug____> | I would assume mutation events have caused crashes also in Opera |
| 08:52 | <smaug____> | :) |
| 08:52 | <jgraham> | (or Linköping, but everyone thinks Opera == Oslo) |
| 08:53 | <smaug____> | (Hmm, have I been in Linköping) |
| 08:53 | <smaug____> | (probably just passed by) |
| 08:58 | <gsnedders> | (Probably just passed by, it's not like anything ever happens here.) |
| 09:01 | <smaug____> | (I've been often in places where nothing really happens. Silicon Valley is one such place.) |
| 09:02 | <jgraham> | gsnedders: You were talking just last night about Judas Priest playing here! |
| 09:02 | <jgraham> | If you want to see 60 year old men in bondage gear, this is the town for you! |
| 09:03 | <gsnedders> | Well, by Lkpg's scale, that's an unprecidented event. |
| 09:03 | <gsnedders> | I never said in more ordinary terms it was notable. |
| 09:44 | <Ms2ger> | "we are close to closing the XSL WG. The XSL FO WG is going to be closed in the next 6 months." |
| 09:44 | <Ms2ger> | Hear, hear |
| 09:49 | <jgraham> | UPDATE W3C.groups SET status='inactive' WHERE name LIKE 'X%'; |
| 10:08 | <charlvn> | lol jgraham |
| 10:33 | <zcorpan> | tabatkins: hsivonen's proposal makes <set> and <image> svg elements |
| 11:21 | <tabatkins> | zcorpan: Yeah, misread. Sorry, hsivonen! |
| 11:31 | <benvie> | seeing all the svg property interfaces blink into existence 5-10 at a time when setting one property due to mutation observers and svg's late init is pretty funny |
| 11:43 | <tabatkins> | SVG has late init? |
| 12:34 | <jarek> | btw, would it be suitable to use mutation observers for implementation of undo manager in SVG editor? |
| 12:35 | <jarek> | I have noticed that SVG-edit is registering undo operations manually which is a bit complicated |
| 12:40 | <zcorpan> | hey everyone! check out the new DOM Parsing spec at http://www.w3.org/TBD |
| 13:11 | <kennyluck> | Hmm.. I don't get that joke. |
| 13:13 | <hober> | kennyluck: it's no joke |
| 13:14 | <hober> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204 |
| 13:16 | <jgraham> | hober: Well it is. Just the other kind of joke |
| 13:17 | <hober> | jgraham: indeed. |
| 13:17 | <zcorpan> | jgraham: what's the idea with setup()? what's supposed to happen when it fails? |
| 13:19 | <jgraham> | zcorpan: In theory the idea is that you put any pre-test setup in that function and testharness.js will report to a higher layer if it fails |
| 13:23 | <zcorpan> | yeah, that's what i thought. it just doesn't seem to work |
| 13:24 | <zcorpan> | my tests still time out even if setup throws |
| 13:24 | <jgraham> | Oh. Well it might be broken in some way I guess |
| 13:27 | <kennyluck> | lol |
| 13:30 | <jgraham> | zcorpan: If you put the test somewhere I can see it I will look |
| 13:56 | <Wilto> | hober: So you’re saying that imgset does not preclude <picture>. |
| 13:56 | <Wilto> | Despite there being some overlap in the concerns they address? |
| 14:00 | <Wilto> | …No, actually, these address the same concerns. |
| 14:01 | <Wilto> | In different ways, but the same core issues. Just, one uses a syntax arrived upon through the consensus of the Community Group, countless blog posts, comments—hell, _tweets_—and one was arrived at after a cursory glance at the CG. |
| 14:02 | <Wilto> | I’m not some especially irritating kid with an opinion here, guys. |
| 14:02 | <Wilto> | I’m representing the developers’ consensus. |
| 14:03 | <Wilto> | So when you say “this syntax is better for authors,” here, in a vacuum, I am here to inform you that we considered something just like this already and nobody liked it. |
| 14:03 | <hober> | I think "a cursory glance" is an unfair characterization of the work that went in here. |
| 14:03 | <Wilto> | Take it or leave it, sure, but don’t pretend the developer consensus is the reasoning behind this proposed syntax when _getting that consensus has been my job_. |
| 14:03 | <jgraham> | Wilto: You would be much more convincing with citations |
| 14:04 | <jgraham> | Specifically to citations to problems with the syntax |
| 14:04 | <jgraham> | Rather than making an argument from authority |
| 14:05 | <Wilto> | Sure. Happy to collect those for you. |
| 14:06 | <hober> | I don't understand what you think I'm pretending. |
| 14:06 | <Wilto> | You can understand where I’m irritated, when the CH was posed as a place to give developers a voice in the creation and adoption of standards, and the _good news_ is that people had a look at it before starting to make decisions. |
| 14:06 | <hober> | (i'm not being intentionally obtuse, btw, i really didn't understand that last line) |
| 14:07 | <hober> | I certainly understand your irritation. |
| 14:07 | <hober> | That said, how some people described a community group isn't something I have any control over |
| 14:07 | <Wilto> | No, of course not. |
| 14:08 | <Wilto> | But like… you saw the number of folks involved in the discussion in the CG, the ALA article, the .net article, likely some of the chatter on Twitter, etc. etc. |
| 14:08 | <Wilto> | Even if the others missed it somehow, man, you’ve seen that this is a big deal. |
| 14:08 | <Wilto> | And no small amount of work has been done. |
| 14:09 | <hober> | is anyone saying that that work hasn't been done? |
| 14:09 | <Wilto> | Hell, not even asking me to get involved—someone could have mentioned that these discussions were kicking off in IRC. |
| 14:09 | <Wilto> | No, not at all. |
| 14:09 | <Wilto> | I’m saying that despite all that, the discussion kicked off in a vacuum. |
| 14:10 | <hober> | (sorry if i'm coming across as short, btw; it's day 3 of the css wg and it's getting kinda punchy in here. good thing the room is padded.) |
| 14:10 | <Wilto> | You’re not working with developers on this. You’re “considering” us. |
| 14:10 | <Wilto> | We planned on working with the WHATWG. |
| 14:10 | <hober> | aren't we working together right now? |
| 14:11 | <hober> | i don't understand "the discussion kicked off in a vacuum" |
| 14:11 | <Wilto> | Hixie already “proposed a solution.” |
| 14:11 | <hober> | there have been many threads on whatwg@ (and elsewhere, obv.) about this |
| 14:11 | <Wilto> | Which is fine, don’t misunderstand. |
| 14:11 | <hober> | yeah, and when he described it i recalled that i had a pending draft email about that, so i dug it up and hit send |
| 14:12 | <hober> | i'm not at the machine that i usually use for email, so it didn't get property threaded as a reply on one of the existing threads |
| 14:12 | <Wilto> | But that’s where I get irritated. So he just whipped that up, and I’m guessing from the responses in general that he had no idea the CG existed, and hasn’t paid much attention to the internet at large talking about respimg. |
| 14:13 | <Wilto> | But that syntax is “better for authors?” What I’m getting at is I’ve, y’know, _asked_ the developers. |
| 14:13 | <hober> | i don't see how you can assert that he "just whipped that up" |
| 14:13 | <jgraham> | Wilto: I don't think getting irritated is going to help you at all |
| 14:13 | <jgraham> | If you have concrete objections to that syntax |
| 14:13 | <jgraham> | make them |
| 14:13 | <hober> | i don't know how much time he spent on it, so i avoid aserting that he spent a lot of time or not much time |
| 14:13 | <jgraham> | Cite the developers |
| 14:13 | <Wilto> | jgraham: Yeah, guess I’m spinning my wheels here. |
| 14:14 | <Wilto> | jgraham: Before I do, are there any citations that Hixie’s proposal is preferred by developers? |
| 14:15 | <zcorpan> | an attribute would be better for *implementors* (because it makes the processing orders of magnitude simpler (which in turn means fewer bugs)) |
| 14:15 | <Wilto> | zcorpan: Citations? |
| 14:16 | <Wilto> | zcorpan: By which I mean, has this been discussed with implementers? |
| 14:16 | <jgraham> | Wilto: zcorpan is an implementor |
| 14:16 | <zcorpan> | Wilto: i've QA'd <video><source> for opera, i know it is orders of magniture more complex than an attribute would be |
| 14:17 | <jgraham> | (it's rather easy to understand why; if you have multiple elements, you can get things like <script> in the middle that add or remove things in real time, whereas attributes can be processed atomically) |
| 14:17 | <Wilto> | Cool. The order of operations for benefit is “users -> developers -> implementors” though, yeah? |
| 14:17 | <jgraham> | Yes |
| 14:17 | <Wilto> | I’m not dismissing what you’re saying, mind. Again, I’ve been working with browser devs right along, and this is important stuff. |
| 14:17 | <kennyluck> | Wilto, I would strongly suggest you write an email to whatwg⊙wo, even just a mail with a pointer to the discussion on CG. No body can read every mail on every mailing list. |
| 14:17 | <zcorpan> | yes. but if the implementors get riddled with bugs, that's not useful for developers either |
| 14:18 | <jgraham> | If you can prove that multiple elements addresses use cases better than a single attribute, that makes a difference |
| 14:18 | <Wilto> | Has this been discussed with reps from any other UAs? |
| 14:18 | <jgraham> | But yeah, all things being equal, avoiding interoperability problems before they have the chance to occur is a win for everyone |
| 14:19 | <Wilto> | Opera doesn’t do anything—or have anything planned—in the way of image prefetching, correct? |
| 14:19 | <hober> | Wilto: when you say "browser devs", do you mean implementors? dev rel? other browser-affiliate people? |
| 14:19 | <Wilto> | Implementors and a few devrel folks. |
| 14:19 | <jgraham> | Wilto: We generally don't talk about the roadmap |
| 14:19 | <jgraham> | Except when we do |
| 14:19 | <zcorpan> | jgraham: you got the meme wrong :-P |
| 14:20 | <jgraham> | zcorpan: I don't know all the memes |
| 14:21 | <gsnedders> | Object.getPrototypeOf(xOriginWindow) doesn't throw anywhere… |
| 14:21 | <Wilto> | jgraham: Well, that’s a pretty major factor in implementation across all the browsers. |
| 14:21 | <zcorpan> | Wilto: i haven't discussed this really until now. but i'm happy to write down the complexity differences between an attribute and elements sometime next week |
| 14:22 | <Wilto> | zcorpan: I’d like to see that, yes. |
| 14:22 | <jgraham> | Wilto: It doesn't seem like it's that complicated really |
| 14:22 | <jgraham> | Wilto: You can DNS prefetch |
| 14:22 | <jgraham> | But you can't speculatively grab the resources in a bandwidth-efficient way |
| 14:22 | <jgraham> | Because it depends on layout which one you pick |
| 14:23 | <Wilto> | jgraham: I can’t speak to that complexity, but I know it has been a major factor in discussions with Chrome. |
| 14:23 | <hober> | jgraham: in my proposal, asset choice doesn't depend on layout. |
| 14:23 | <Wilto> | I’m happy to revisit that and post the results—or the discussion itself—publicly. |
| 14:23 | <hober> | jgraham: one of the differences between hixie's and mine |
| 14:23 | <jgraham> | hober: Oh. |
| 14:23 | <jgraham> | That seems to address fewer use cases? |
| 14:23 | <hober> | yup |
| 14:24 | <zcorpan> | now, nice weekend everyone :-) |
| 14:24 | <hober> | jgraham: the perfect is the enemy of the good :) |
| 14:24 | <hober> | jgraham: baby steps and all |
| 14:24 | <jgraham> | OK, I guess you can always ditch use cases in order to get prefetching working |
| 14:24 | <jgraham> | hober: Sure, I don't know what the right compromise is, exactly |
| 14:29 | <Wilto> | The idea for a new element came about because we were looking for a way to preserve prefetching—or at least sandbox any custom prefetching behavior—without abandoning functionality. |
| 14:30 | <jgraham> | I don't understand how element vs attribute can affect prefetching. I understand that not depending on layout can affect what prefetching you can do at the expense of not meeting all the use cases |
| 14:33 | <Wilto> | jgraham: I’ll gather more information on that. |
| 14:39 | <Wilto> | I’m going to post these discussions to the Community Group; just a heads-up. |
| 14:40 | <Wilto> | And the associated proposals. |
| 14:40 | <Wilto> | And reach out to the developer community to voice their preference. Would anyone like to be the primary point of contact for that, or should I direct them to the WHATWG at large? |
| 14:41 | <jgraham> | To the WHATWG |
| 14:42 | <hober> | whatwg⊙wo is the right place. n.b. "+1" posts (posts which express a preference but do not make a novel point) are discouraged on the whatwg list. |
| 14:42 | <jgraham> | If you email the WHATWG list then nothing will get lost |
| 14:46 | <Wilto> | Sure; sounds good. |
| 14:46 | <kennyluck> | Seriouly, I don't quite buy any "theories" with bikeshedding issues and in that case voting just helps. |
| 14:47 | <Wilto> | I’ll encourage people to sound off with their +1s in another forum, since a big part of this discussion seems to be developer preference. |
| 14:47 | <Wilto> | The list may not be the right place for it, but it should be recorded. |
| 14:50 | <kennyluck> | Wilto, agreed. Hixie ought to consider a poll as "data", but I think he prefers to call it "usability research". I don't quite know the difference but he might be able to give you some hints. |
| 14:52 | Philip` | guesses the difference is that polls are usually biased towards groups with the strongest opinions and with the widest ability to convince other people to vote, whereas usability research tries to get a smaller but more representative sample |
| 14:54 | <jgraham> | If developers have a preference, they should articulate *why* they prefer one form over another |
| 14:56 | <Wilto> | Well, I’ve been taking on a firehose of developer opinions on this subject for months. Which is not so much like “herding cats” as it is “herding YouTube commenters.” |
| 14:57 | <hober> | wheee! :) |
| 14:57 | <Wilto> | I could cite all the discussions on the CG, and gather up links to offsite stuff, or I can just tell them to get involved in these discussions. You’re gonna get some +1s—and naturally a reasoned argument would be preferable—but they shouldn’t be discounted entirely either. |
| 14:58 | <Wilto> | hober: Man oh man, do folks have Opinions on the Internet. |
| 15:43 | <karlcow> | +1 to the above |
| 15:44 | <hober> | Wilto: indeed. http://xkcd.com/386 |
| 16:10 | <dglazkov> | good morning, Whatwg! |
| 17:12 | <staydecent> | <source src="... looks redundant |
| 17:14 | <barnabywalters> | staydecent: what would you suggest? |
| 17:17 | <staydecent> | Why not have all elements within <picture> be <img>? |
| 17:18 | <barnabywalters> | could that not cause serious backwards compatibility problems? |
| 17:18 | <staydecent> | ah.. right. Old browser would just ignore the <source> elements? |
| 17:19 | <barnabywalters> | yep |
| 17:19 | <barnabywalters> | that's the beauty of the <picture> element + fallback (although I hate the name. It's like calling <video> <film>) |
| 17:19 | <Wilto> | staydecent: Current browser behavior is just to find the src, and then “case closed.” Old browsers would ignore them, but so would new ones without some major parsing changes. |
| 17:20 | <Wilto> | barnabywalters: Hah, I don’t love `picture` either, truth be told. Every time we raise the issue, though, no one has anything better. |
| 17:21 | <staydecent> | Yeah. i agree I find the <picture> element much more readable for developing than the set attr. But, the naming is a little off. But again, I have no suggestions atm |
| 17:21 | <barnabywalters> | hmmm... I read <image> is an alias for <img>, so if that's true that wouldn't work |
| 17:21 | <ShaneHudson> | Somebody mentioned in the comments about calling it <image>... I think it would work, more consistant without being confusing |
| 17:21 | <Wilto> | barnabywalters: Yeah, a lot of older browsers treat img and image the same. |
| 17:21 | <zcorpan> | s/a lot of older// |
| 17:22 | <othermaciej> | barnabywalters: I think <movie> and <sound> might have been fine names for <video> and <audio> |
| 17:22 | <Wilto> | Which stands to introduce Troubles. |
| 17:22 | <staydecent> | how much older? |
| 17:22 | <zcorpan> | the html spec requires <image> to be parsed as <img> |
| 17:22 | <Wilto> | zcorpan: Is that right—current, too? Admittedly, someone else ran those tests and reported back. |
| 17:22 | <staydecent> | ah |
| 17:22 | <barnabywalters> | <sound> might have been alright, but I don't like <movie> |
| 17:22 | <zcorpan> | Wilto: current too, yeah. pages depend on it. :( |
| 17:23 | <Wilto> | “Oh, what a tangled web we weave.” |
| 17:23 | <ShaneHudson> | How about <responsive> since <picture> includes <img> inside of it, rather than replacing |
| 17:23 | <barnabywalters> | that's a bit ambiguous |
| 17:24 | <Wilto> | Yeah—and kind of hitches our horses to that term. I loves me some RWD of course, but… |
| 17:24 | <ShaneHudson> | True, it is too much of a buzzword as it is |
| 17:25 | <staydecent> | This is a bit of a braindump, but: what about <media> which could expand to have <source>...etc. and then either <img> or <video>? |
| 17:26 | <barnabywalters> | staydecent: so you'd have something like <media type="video"> |
| 17:26 | <staydecent> | Maybe that conflicts with media-queries tho. |
| 17:26 | <staydecent> | yeah |
| 17:26 | <zcorpan> | let's not complicate <video> |
| 17:26 | <ShaneHudson> | I like the idea of giving chance for <video> as well as <img> but I am not sure if there would be troubles with implementations |
| 17:27 | <othermaciej> | <video> already has media-query-based responsiveness |
| 17:27 | <Wilto> | I’m with zcorpan there. |
| 17:27 | <othermaciej> | also, the <element type=actual-element> pattern is kinda lame |
| 17:27 | <ShaneHudson> | Would it be completely stupid to have <img> as the main element with optional sources inside? <img src="default"><source></img> |
| 17:27 | <othermaciej> | it's only really useful for <input> since it falls back to a text input, which is often a reasonable choice |
| 17:27 | <barnabywalters> | yeah, agreed. Doesn't seem very stable |
| 17:27 | <Wilto> | It’s tough because this topic feels like an opportunity to address so many other, related issues. |
| 17:27 | <zcorpan> | othermaciej: i argued on the list that <source media> is the wrong solution and maybe should be dropped :-) |
| 17:27 | <zcorpan> | (for video) |
| 17:27 | <Wilto> | But we can’t, y’know? |
| 17:27 | <othermaciej> | zcorpan: I do wonder if anyone is using it |
| 17:28 | <othermaciej> | zcorpan: the original purpose was for (rather hypothetical) accessibility-related and bandwidth-related additions to media queries |
| 17:28 | <othermaciej> | <source> mainly seems useful only for content type selection |
| 17:28 | <zcorpan> | othermaciej: indeed |
| 17:29 | <barnabywalters> | that's a very good point - using source for images would be inconsistent with video |
| 17:29 | <zcorpan> | othermaciej: i think it makes more sense to use something like "adaptive streaming" with a single <source> URL to switch streams |
| 17:29 | <zcorpan> | since bandwidth and wanted resolution can change over time |
| 17:29 | <barnabywalters> | zcorpan: can you go into more detail about how that would work? |
| 17:29 | <othermaciej> | adaptive streaming does make more sense as an approach to video |
| 17:29 | <staydecent> | Would you need the attr type="video" tho? |
| 17:29 | <othermaciej> | not really as sensible for static images |
| 17:30 | <Wilto> | Let’s not get too bikeshed-y in here though, guys. |
| 17:31 | <Wilto> | The community group is great for this stuff; I’d like to keep the brainstorming in there, if that’s cool. |
| 17:31 | <zcorpan> | barnabywalters: something like apple's "adaptive streaming" thing for mpeg4, but not necessarily exactly that |
| 17:31 | <barnabywalters> | so pushing the responsibility more towards the browser manufacturers? |
| 17:32 | <zcorpan> | compared to what? |
| 17:32 | <zcorpan> | <source media> is the responsibility of the browsers too |
| 17:32 | <barnabywalters> | compared to picture where the authors decide what images they're providing and when to display them |
| 17:32 | <ShaneHudson> | It would make it a lot easier for general users defintely... it is easy to learn about <img> but <picture> (although the best soloution so far) is pretty complicated |
| 17:33 | <zcorpan> | i'm talking about <video> right now :-) |
| 17:33 | <barnabywalters> | ah, my bad :) |
| 17:33 | <ShaneHudson> | Hey chriscoyier :) |
| 17:33 | <zcorpan> | for images, adaptive streaming doesn't make much sense, as othermaciej said |
| 17:34 | <staydecent> | What about <picture> -> <imagegroup>? |
| 17:34 | <zcorpan> | i guess i should write that email about complexity with <source> vs an attribute |
| 17:34 | <barnabywalters> | staydecent: to me, imagegroup implies a group of related but distinct images |
| 17:34 | <othermaciej> | for video, you really want to change bandwidth/quality tradeoff in the middle of playback rather than loading a whole new resource |
| 17:34 | <othermaciej> | for still images, you could at most select once |
| 17:35 | <staydecent> | barnabywalters: I feel like you guys have thought on this quite well. Good point. |
| 17:35 | <othermaciej> | for resolution-based decisions, media queries it seems are not really sufficient, given the implied semantic of scaling in accordance with the scale factor used for selection |
| 17:35 | <zcorpan> | othermaciej: yeah. if you chime in and say so on the list, maybe we can kill <source media> now :) |
| 17:35 | <zcorpan> | (i think opera is the only one to have implemented it, though mozilla are apparently working on it right now) |
| 17:35 | <staydecent> | can I check some logs somewhere for alternate suggestions that have been made for <picture>? |
| 17:36 | <barnabywalters> | staydecent: TBH I prefer it to <picture>, but I don't think it's right, as such |
| 17:36 | <ShaneHudson> | I agree that <imagegroup> feels more like a list tag than alternatives |
| 17:37 | <padenot> | zcorpan: I just finished the patch to have <source media>, it is landing today, afaik |
| 17:37 | <zcorpan> | othermaciej: (subject "Re: [whatwg] <source> media attribute behavior, static or dynamic ?" on whatwg) |
| 17:37 | <zcorpan> | padenot: ah |
| 17:37 | <padenot> | zcorpan: in Gecko, that is |
| 17:37 | <zcorpan> | padenot: do you think it is a useful feature? |
| 17:37 | <othermaciej> | zcorpan: I have to think about it more before saying anything definitive |
| 17:37 | <padenot> | zcorpan: it can have its use, but I don't expect a lot of people to use it |
| 17:38 | <zcorpan> | padenot: what would it be useful for? |
| 17:38 | <padenot> | zcorpan: get scaled down video on mobile |
| 17:39 | <zcorpan> | padenot: but it's not really appropriate for that, afaict (as i said on the list) |
| 17:39 | <padenot> | zcorpan: the bandwith problem is likely to be addressed by dash |
| 17:39 | <zcorpan> | dash? |
| 17:40 | <padenot> | zcorpan: http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP |
| 17:40 | <zcorpan> | ah. right. why isn't that a better solution to the mobile problem than media=""? |
| 17:42 | <padenot> | zcorpan: i don't know enough about dash yet to provide a good answer, i think |
| 17:42 | <staydecent> | Sorry if this is the wrong place: Where does current support lean regarding <picture> vs set=""? |
| 17:43 | <padenot> | zcorpan: don't know if we can request specifically a resolution or the like |
| 17:44 | <zcorpan> | padenot: but the browser would be able to "adapt" to a resolution that currently fits the viewing device, right? |
| 17:44 | <jgraham> | ~. |
| 17:44 | <othermaciej> | on mobile you may want to serve different size rather than different quality (these are generally separate parameters to the encoding process) |
| 17:44 | <othermaciej> | but generally this is done by UA sniffing |
| 17:45 | <ShaneHudson> | For a renaming of <picture>... what about <quality> or <version>? Too 'meta'? |
| 17:45 | <padenot> | zcorpan: I think it is reasonnable to say that, but I don't know for sure |
| 17:45 | <barnabywalters> | shanehudson: you're talking about renaming the <source> child tags? |
| 17:46 | <barnabywalters> | or the <picture> tag it's self? |
| 17:46 | <ShaneHudson> | barnabywalters: I was thinking more of <picture> to <versions> or something |
| 17:47 | <barnabywalters> | ShaneHudson: I think the root element should describe the content type. Otherwise things could get sticky later on |
| 17:47 | <barnabywalters> | e.g. for different content types, content types that don't even exist yet, etc |
| 17:48 | <ShaneHudson> | fair enough, in an ideal world it would be nice to be able to work with any content type, but that is of course not the case |
| 17:49 | <Zunflappie> | What about CSS > instead of background-image also a front-image? As a overlay over the image? <img src="small.jpg" style="front-image: url(big.jpg); media=min-400px"> |
| 17:49 | <Zunflappie> | I dont know the right syntax for inline style with media-queries, but you got the point? |
| 17:50 | <staydecent> | Zunflappie: that would load both images though? |
| 17:50 | <Zunflappie> | Yeah, but dont need javascript. |
| 17:50 | <barnabywalters> | Can I get people's opinion on this syntax: http://jsfiddle.net/aZ37N/ -- would there be any serious backward compatibility/other problems? |
| 17:51 | <barnabywalters> | the <version> is hypothetical, it's using the <img> tag as a wrapper I'm interested in |
| 17:51 | <Zunflappie> | Look good, only the <version> is strange. |
| 17:51 | <Zunflappie> | </img> isnt needed, but should be a big thing to learn |
| 17:51 | <barnabywalters> | sure, as I say, I think that needs to be given more thought as to naming/exact syntax |
| 17:51 | <Zunflappie> | Indeed, it sounds / reads good |
| 17:52 | <barnabywalters> | Zunflappie: the </img> is the whole point — using the <img> as a fallback and also the wrapper for alternate sources |
| 17:52 | <barnabywalters> | e.g. we change <img> to be a non-self-closing tag (or whatever terminology) |
| 17:53 | <staydecent> | barnabywalters: I like your proposition. Having the img element as the parent makes sense to me |
| 17:53 | <MikeSmith> | barnabywalters: there are serious backward-compatibility problems |
| 17:53 | <Zunflappie> | Euh... yeah. Not like <hr> but as <caption>. And maybe <video> also? <video src="normal.avi"><... src="large"></video> |
| 17:53 | <barnabywalters> | MikeSmith: I thought as much ;) |
| 17:54 | <staydecent> | damn, backwards compatibility is no fun. |
| 17:54 | <MikeSmith> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cimg%20src%3D%22Mobile.jpg%22%20alt%3D%22%22%3E%0A%20%20%20%20%3Cversion%20src%3D%22med-res.jpg%22%20media%3D%22%22%20%2F%3E%0A%20%20%20%20%3Cversion%20src%3D%22hi-res.jpg%22%20media%3D%22%22%20%2F%3E%0A%3C%2Fimg%3E |
| 17:55 | <gorh> | hi there |
| 17:56 | <barnabywalters> | MikeSmith: I'm missing something here — what is the problem you're highlighting in that page? |
| 17:56 | <Zunflappie> | There was nog closing-tag for the option (like </option>) |
| 17:56 | <MikeSmith> | your first version element becomes a sibling of the img, not a child, and the second version element becomes a child of the first one |
| 17:57 | <MikeSmith> | we can't change the parsing behavior for img |
| 17:57 | <Zunflappie> | <img src="..."><option src="..."></option></img> could work? |
| 17:57 | <barnabywalters> | ah, okay |
| 17:57 | <Zunflappie> | So both <options> <captions> are first-generation-children of <img>? |
| 17:58 | <ShaneHudson> | barnabywalters: I *really* like that syntax (<img><version></img) but I expect there would be some major problems wtih compatibility |
| 17:58 | <barnabywalters> | Zunflappie: even if we added closing tags to the source selection tags, they'd still be siblings, not children of <img> |
| 17:58 | <jgraham> | The only solution involving <img> that can work is to put all the sources in an attribute |
| 17:59 | <jgraham> | You *can't* change the parsing of <img> |
| 17:59 | <jgraham> | (or <image>) |
| 17:59 | <Zunflappie> | Such as <img src="small.jpg" medium="middle.jpg" large="giant.jpg"> ? |
| 17:59 | <barnabywalters> | jgraham: indeed. Looks like using <img> isn't likely to work |
| 17:59 | <Zunflappie> | <picture> as alternative/extra is then a good thing? |
| 17:59 | <gorh> | hé hé i see i arrived in the right discution :) |
| 17:59 | <jgraham> | Zunflappie: There is a better proposal (imho) on the whatwg list |
| 18:00 | <ShaneHudson> | It will not work as attributes |
| 18:00 | <staydecent> | Sorry to diverge a bit here, but this article is confusing: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ -- Which group proposed the picture solution? |
| 18:00 | <jgraham> | ShaneHudson: Why not? Did you see the proposal on that whatwg list? |
| 18:00 | <ShaneHudson> | The syntax for set for example looks horrid and would be hard for even us to get to grips with, let alone beginners |
| 18:00 | <barnabywalters> | ShaneHudson: agreed. set="" is horrible |
| 18:00 | <Zunflappie> | Staydecent: thats the page why I turned here in. The <picture> looks good to me, as <img> is still there. |
| 18:01 | <gorh> | i have to say that i, too would prefer by far <picture><source ... to the attribute way, at least for the sake of my eyes ) |
| 18:01 | <staydecent> | I agree as well. I am in favour of <picture> over the set attr. Just confused as to who has proposed what. |
| 18:01 | <ShaneHudson> | Yeah I have been following <picture> for quite a while. I do not believe it is the best soloution, but certainly superior to set="" |
| 18:01 | <barnabywalters> | the tag based approach would also be easier to generate/parse in code |
| 18:01 | <Zunflappie> | Is is possible to work only with <img>'s? <picture><img src="small" media="min-width: 400px;"><img src=""><img src=""></picture> |
| 18:02 | <ShaneHudson> | Nope |
| 18:02 | <Zunflappie> | Or does that render always 3 images (so small, middle and large?) |
| 18:02 | <staydecent> | yeah for older browsers would render all 3 |
| 18:02 | <ShaneHudson> | Since that would (on older browsers at least) render all of them |
| 18:02 | <gorh> | tbh i can cope with throwin <img> tag away ;) |
| 18:03 | <barnabywalters> | gorh: not if you want to support older browsers, surely? |
| 18:03 | <ShaneHudson> | Wouldn't it be nice to start with a clean slate! |
| 18:04 | <barnabywalters> | ShaneHudson: indeed :( That'd be no fun though :) |
| 18:04 | <staydecent> | Lol, Legacy is never fun. But necessary. |
| 18:04 | <gorh> | yep sure, but this can be coped as well lest say by hiding img via css for regular users |
| 18:05 | <gorh> | but i see the point on keeping the legacy browsers in the scope |
| 18:05 | <staydecent> | gorh: but then the image would still be downloaded by the user |
| 18:05 | <Zunflappie> | Exactly. What about IE6 or 10 year old machines (not callling them phones...). <picture> is like <video>, what is a good point. But i like a 3-letter-shortcut (like IMG for IMAGE) more. <VID> maybe? |
| 18:06 | <staydecent> | gorh: a goal of responsive images is not to force a mobile phone to download more than it needs to |
| 18:06 | <Zunflappie> | Hiding with CSS doesnt prevent downloading its contents! |
| 18:06 | <barnabywalters> | Zunflappie: that's interesting, I prefer full words to the abbreviations |
| 18:06 | <Zunflappie> | So you like <division> and <italic>? |
| 18:06 | <Zunflappie> | Or what about <tr>???? |
| 18:06 | <barnabywalters> | Zunflappie: within reason :) |
| 18:06 | <gorh> | yep sure, but i say do that by css, but there are plenty of other way to do so |
| 18:07 | <barnabywalters> | okay, <table-row> or <abbreviation> are a bit of a mouthful, but I think <video> is fine |
| 18:07 | <Zunflappie> | Yeah, Server-side. Otherwise it will get a HTTP-request |
| 18:07 | <staydecent> | gorh: CSS can't prevent a device from downloading the orginal image |
| 18:07 | <gorh> | css can't |
| 18:07 | <gorh> | but don't tell me that there is no other way ) |
| 18:08 | <Zunflappie> | Javascript either..... only php/ruby on rails >> server, as the html should be altered |
| 18:08 | <Zunflappie> | And then... you must sniff the device first. That's not RESPONSIVE! |
| 18:10 | <Zunflappie> | Hereby its all said? |
| 18:11 | <ShaneHudson> | It is a shame there is not yet anyway to do responsive images without a multitude of them. Keep the original <img> tag and automatically make "responsive" |
| 18:12 | <barnabywalters> | ShaneHudson: I think someone has done that on the server side with cookies, generating a different copy of the image |
| 18:12 | <gorh> | no but infact i'm not that much attached to the <picture> tag, what annoys me the most is the attribute way |
| 18:13 | <Zunflappie> | <ShaneHudson: There is a manner with Javascript. But it takes also PHP for the correct sizes/urls |
| 18:13 | <ShaneHudson> | I am thinking browser side.. I have seen adaptive images etc. but none of them seem perfect for the job |
| 18:13 | <ShaneHudson> | Maybe it will come when we have bandwidth sniffing or something like that |
| 18:13 | <Zunflappie> | As there cant be a horse.jpg (small), horse.jpg (medium) and a horse.jpg (large)..... Or it must be in folders: .../small/horse.jpg and .../medium/horse.jpg etc |
| 18:14 | <Zunflappie> | that IO.<something) has that sniffing? |
| 18:14 | <gorh> | and, i also realise that it mainly is about code readability ... wile i should focus on the usability |
| 18:14 | <ShaneHudson> | The only one I know is foresight.js |
| 18:14 | <Zunflappie> | See http://css-tricks.com/which-responsive-images-solution-should-you-use/ >> |
| 18:14 | <Zunflappie> | Sencha.IO (based on foresight.js) |
| 18:14 | <Jayflux> | Can anyone tell me the point of the <embed> tag? all browsers seem to work fine without it when the attributes are put on the object tag instead, it also validates properly. |
| 18:15 | <ShaneHudson> | Jayflux: I believe that was to do with ie5.5? May well be wrong though |
| 18:15 | <gorh> | but, tbh, with daily uses, i prefer from far working on readable code rather than looooooong tags |
| 18:15 | <ShaneHudson> | defintely |
| 18:16 | <Jayflux> | so it may aswell be obsolete ShaneHudson ? |
| 18:16 | <Jayflux> | in terms of today usage |
| 18:16 | <ShaneHudson> | Jayflux: I believe so, but it is not an area I pay much attention to tbh |
| 18:17 | <Zunflappie> | What is 'tbh'? Probaly not The Birthday Hub.... :P |
| 18:17 | <gorh> | to be honest |
| 18:18 | <Zunflappie> | ok! When does w3c comes with a poll? |
| 18:19 | <gorh> | what i mean is that, the <picture way is more developer friendly, and the <img set...> one is more browser friendly, and i'm still no sure if i prefer or to have to deal with both syntax and compatibility, and have something easy to read |
| 18:19 | <gorh> | or to have each img tag filling lines and lines of not explicit code |
| 18:21 | <barnabywalters> | gorh: I think one of the great things about HTML is it's ease of use. It's really easy to understand, and it'd be a pity to lose that, especially on something as fundamental as an image |
| 18:22 | <staydecent> | Is there any course of action to help picture get implemented over img set? I guess being in this IRC? |
| 18:23 | <Zunflappie> | Good point barnabywalters! So always maintain current syntaxes |
| 18:23 | <gorh> | barnabywalters: i totaly agree on that this is why i like the <picture> way ) |
| 18:23 | <Zunflappie> | And more: its like the new <video> and <audio>..... make <embed> and <object> the same syntax? |
| 18:24 | <ShaneHudson> | staydecent: http://www.w3.org/community/respimg/ |
| 18:24 | <gorh> | Zunflappie: you really find the attribute way more clear ? |
| 18:24 | <Zunflappie> | As a browser supports html5, it can be doen |
| 18:24 | <staydecent> | ShaneHudson: Thanks |
| 18:24 | <barnabywalters> | Zunflappie: actually, the similarity to <video> and <audio> is something I'm uncomfortable about |
| 18:24 | <Zunflappie> | Gorh: like <img src="small.jpg" medium="middle.jpg" .......> atc? |
| 18:25 | <gorh> | as simple as that that would be a dream ) |
| 18:25 | <Zunflappie> | <video> <audio> and <picture> are all media? More then text can't video/audio/picture realign or crop. Audio is special (as it doenst need take space in a page) |
| 18:25 | <barnabywalters> | as video and audio's <source> choses different codecs based on browser compatibility, whereas proposed picture <source> choses a different size based on screen size — so very different meanings to the same syntax |
| 18:26 | <gorh> | but what about breakpoint to choose image etc etc |
| 18:26 | <lorin> | Zunflappie: xlarge jumbo gojira |
| 18:26 | <barnabywalters> | gorh: Yes, <img src="" medium="" etc is inflexible. In fact, html used to have lowsrc="" or something |
| 18:26 | <barnabywalters> | so that'd almost be a step backwards :) |
| 18:27 | <Zunflappie> | lorin: thats a point. Anno 2012 we want 3 sizes... but what if I want 4 or 5? lowsrc="" works a bit, but aint flexible. It was only a idea. |
| 18:27 | <gorh> | one tag to define 3 or more image path and beahvior ... it implies a tag too long in my opignon |
| 18:27 | <Zunflappie> | <picture> with media-queries are better.... but i hate the syntax of the queries. MIN and MAX could be better for me. |
| 18:28 | <barnabywalters> | Zunflappie: agreed, I'm not sure about using media queries as the syntax |
| 18:28 | <barnabywalters> | as they assume that small screen size = smaller bandwidth |
| 18:28 | <ShaneHudson> | which is completely wrong. My home wifi is slower than 3G lol |
| 18:28 | <Zunflappie> | Thats not a problem, but more when i resize my window |
| 18:29 | <Zunflappie> | Shane: haha, fix your Wifi then :P |
| 18:29 | <ShaneHudson> | House is too far away from the exchange sadly. But luckily here at uni I am on fibre :D |
| 18:29 | <barnabywalters> | ShaneHudson: I get that sometimes. Mine has really bad range, I have to use 3G when I'm upstairs sometimes |
| 18:30 | <Zunflappie> | Oke. I hope i haved helped the whatwg to choose for <picture> or something else. Nevermind.... but please: choose fast. |
| 18:30 | <Zunflappie> | Its 20:30... time for Top Gear (and beer and chips) |
| 18:31 | <staydecent> | Zunflappie: Haha, enjoy! |
| 18:32 | <gorh> | long live to the <picture> tag :) i'm off a well ) |
| 18:36 | <staydecent> | Anyone willing to recap the issues/limitations of the <picture> tag besides semantics? |
| 18:37 | <ShaneHudson> | http://trac.webkit.org/changeset/111637 Image-Set in webkit |
| 18:38 | <barnabywalters> | ShaneHudson: I just found a link to that too, I can't really make much sense of how it could be used though |
| 18:39 | <barnabywalters> | ah, http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html explains it better |
| 18:39 | <ShaneHudson> | Hmm yes I see, so it is like <picture> but for css backgrounds |
| 18:40 | <ShaneHudson> | The syntax of that actually looks fairly nice |
| 18:40 | <barnabywalters> | There's some good explanations of why several options wouldn't work (including the one I suggested earlier) here: https://etherpad.mozilla.org/responsive-assets |
| 18:41 | <ShaneHudson> | *bookmarked* |
| 18:41 | <ShaneHudson> | That is a very good article |
| 18:41 | <ShaneHudson> | well, document :O |
| 18:41 | <barnabywalters> | even better, as (I think) we can edit it |
| 18:41 | <ShaneHudson> | yeah |
| 18:42 | <staydecent> | is that content pretty much the same as : http://www.w3.org/community/respimg/wiki/Main_Page |
| 18:42 | <ShaneHudson> | yeah very similar |
| 18:43 | <staydecent> | Shoot, now I'm leaning towards the image-set CSS approach: http://www.w3.org/community/respimg/2012/04/08/using-css-to-control-image-variants/ |
| 18:44 | <staydecent> | But, how could that work with CMS's? |
| 18:44 | <barnabywalters> | staydecent: it looks alright for images specified through css, I can't see anything about using it in markup |
| 18:44 | <ShaneHudson> | image-set is good for backgrounds, but not for images since they are usually part of the content rather than layout, and you would not want css for each and every image! |
| 18:45 | <staydecent> | Good points |
| 18:45 | <padenot> | /b 9 |
| 18:45 | <barnabywalters> | I suspect that image-set could work nicely alongside a markup solution though |
| 18:51 | <zcorpan> | Wilto: ok i've sent an email to whatwg now. lemme know whether it makes sense |
| 18:52 | <Matt__> | Hello |
| 18:52 | <staydecent> | Just found this <picture> Polyfill: https://github.com/scottjehl/picturefill/blob/master/picturefill.js good way to test out how the proposed implementation would "feel" |
| 18:52 | <Matt__> | Sorry, hang on while I drag up my IRC knowledge from the depths of time and figure out how to change my name.... |
| 18:52 | <ShaneHudson> | Do /nick "name" |
| 18:53 | <Matt__> | Thanks Shane |
| 18:53 | <ShaneHudson> | I take it we are all agreed that set="" is the wrong way to go? |
| 18:53 | <Matt__> | Set is the wrong way to go |
| 18:53 | <barnabywalters> | ShaneHudson: agreed |
| 18:54 | <Matt__> | Seem /nick "MattWilcox" didn't work ;) |
| 18:54 | <ShaneHudson> | really? strange |
| 18:54 | <tomasf> | try without the quotes |
| 18:54 | <ShaneHudson> | I still really like the <img><version></img> idea, shame that it would break everything! |
| 18:55 | <Matt__> | Might be something to do with being on webchat.freenode.net? I don't know, I've not used IRC in a decade or so. |
| 18:55 | <MattWilcox> | Ah ha! |
| 18:55 | <MattWilcox> | Thanks |
| 18:55 | <ShaneHudson> | Heh yeah I shouldn't have included the quotes |
| 18:56 | <staydecent> | ShaneHudson: Agreed. I also am against the set attribute. |
| 18:56 | <MattWilcox> | I don't think the picture element is perfect, it needs refinement in another revision really. |
| 18:56 | <ShaneHudson> | MattWilcox: most of us seem to like the <picture> but feel it is the wrong name? |
| 18:57 | <ShaneHudson> | What would you say needs to change about it? |
| 18:57 | <zcorpan> | for people not reading the list, please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035784.html |
| 18:57 | <MattWilcox> | But it's a problem not unique to picture, but to the whole "adaptive" methodology that's in HTML at the moment. |
| 18:58 | <MattWilcox> | Shane: The problem is it being too impractical for real world use *en mass* - my thoughts were written up here: http://mattwilcox.net/archive/entry/id/1081/ |
| 18:58 | <MattWilcox> | And I proposed a solution here, which was put the the RespImg group, and HTMLWG mailing list: http://mattwilcox.net/archive/entry/id/1082/ |
| 18:59 | <staydecent> | zcorpan: Thanks, that's a good writeup. |
| 18:59 | <ShaneHudson> | Hmmm, not entirely sure I like the breakpoint syntax but it certinally does make sense |
| 18:59 | <zcorpan> | staydecent: thanks |
| 19:00 | <staydecent> | zcorpan: are the issues with <picture> shared with <video>? |
| 19:01 | <MattWilcox> | Shane: I'm open to refinement and ideas, the syntax I put there was literally a first idea. |
| 19:01 | <MattWilcox> | Thing is, what I propose is something that can be factored on-top of the existing <picture> proposal if we're desperate to ship now. |
| 19:02 | <zcorpan> | staydecent: <video><source> is very complex for much the same reasons, yes, but is different (maybe even more complex) because the loading algorithm tries to load each <source> in turn, with potential for scripts to change things around at any point |
| 19:02 | <ShaneHudson> | Yeah, I get the idea and am not sure how it could be improved off the top of my head. Seems slightly "clunky" but it would only need to be written once |
| 19:03 | <MattWilcox> | Shane - yep, that's the huge benefit of that approach. And I agree that it's a bit verbose; so is <picture> itself. |
| 19:04 | <staydecent> | zcorpan: do current implementations deal with that in anyway? More so, has work been done already to deal with parsing all the source tags? |
| 19:04 | <ShaneHudson> | Maybe from a naming point of view, case changes to name, and match changes to case? |
| 19:04 | <zcorpan> | staydecent: <picture> would try to find a "best match" source, and could decide to change the source when the environment changes, so it's not the same algorithm as <video><source> at all really |
| 19:04 | <staydecent> | zcorpan: ahhh ok. that makes sense |
| 19:04 | <MattWilcox> | Yeah, perhaps. The naming itself doesn't bother me - that's implementation detail. It's the pattern I like. |
| 19:04 | <zcorpan> | staydecent: we have suffered with bugs with <video><source> because of its complexity |
| 19:05 | <staydecent> | zcorpan: in that case and out of curiousity what is your stance on picture vs img set? |
| 19:05 | <MattWilcox> | zcorpan: Yeah, but it works, right? So why not re-use it. |
| 19:06 | <zcorpan> | staydecent: as i said in the email, i think an attribute is simpler and would be a shorter path to interop |
| 19:06 | <barnabywalters> | MattWilcox: the <video><source> model has a different semantic meaning to the proposed <picture><source> |
| 19:06 | <barnabywalters> | and, as zcorpan says, there have been bugs |
| 19:06 | <zcorpan> | MattWilcox: i doubt all browsers follow the spec to the letter with <video><source> today. i know opera has bugs, and yet i think opera is *most* closely aligned with the spec |
| 19:06 | <MattWilcox> | I am not bothered about the ease with which vendors can implement a feature. That's done *once* in the life of HTML. It is FAR more important the syntax be flexible and easy to understand because millions of authors will learn and use it every day. |
| 19:07 | <zcorpan> | MattWilcox: also, as i said, we can't reuse the same code because <video><source> is not a best match |
| 19:07 | <staydecent> | zcorpan: ah didn't realise that was you. well, this changes my opinion quite a bit. Maybe Ill spend more time thinking about possible improvments to the set attr syntax |
| 19:08 | <MattWilcox> | zcorpan: hmm, not a best match? I have a feeling it's more complex an issue than it seems from my perspective. |
| 19:08 | <staydecent> | have there been any proposals in terms of bandwidth queries? Or is that something for far-off in the future? |
| 19:08 | <MattWilcox> | Bandwidth MQs have been requested for months |
| 19:08 | <zcorpan> | MattWilcox: <video><source> tries to play each <source> in turn, and stops when it has found one that plays |
| 19:08 | <MattWilcox> | But I don't know of any talk about implementation details. |
| 19:09 | <zcorpan> | MattWilcox: <picture> wants to decide which <source> is the best one, and load that |
| 19:09 | <staydecent> | Right, but the img set attr doesn't follow MQ syntax, unless I;m mistaken |
| 19:09 | <annevk> | hober: btw, does viewport width really depend on layout? |
| 19:09 | <MattWilcox> | zcorpan: ah, OK then the beaviour is quite different despite the syntax being similar |
| 19:09 | <zcorpan> | MattWilcox: (and probably do it later again when the environment has changed) |
| 19:09 | <annevk> | hober: because that seems like something that's an input to layout and is therefore already known |
| 19:09 | <zcorpan> | MattWilcox: indeed |
| 19:09 | <annevk> | hober: and can therefore be used at fetching time easily enough |
| 19:10 | <zcorpan> | staydecent: i think using MQ is also inappropriate, but for a different reason |
| 19:10 | <MattWilcox> | zcorpan: would it not be the same if <picture> was extended so that it could deal with requesting different file formats? |
| 19:11 | <MattWilcox> | zcorpan: one thing I'd have liked <picture> to adopt is some method of making it much easier for new file formats like WebP to become practically usable - by offering fallbacks. |
| 19:11 | <staydecent> | zcorpan: I agree. I feel MQ should stay within CSS. |
| 19:11 | <zcorpan> | MattWilcox: different file formats isn't the use case we're trying to solve |
| 19:11 | <staydecent> | But I can't stand the <img set> syntax as it stands here: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ |
| 19:11 | <MattWilcox> | zcorpan & staydecent: I thing they should be moved OUT of CSS and put predomenantly into the <head> |
| 19:12 | <ShaneHudson> | staydecent: Yeah, I can understnd why they thought of it but it would be terrible to add images like that |
| 19:12 | <MattWilcox> | zcorpan & staydecent: but with CSS having the ability to over-ride as needed. See http://mattwilcox.net/archive/entry/id/1082/ for why |
| 19:13 | <MattWilcox> | I think the RespImg Group would have looked at adapting <img> more if Hicksie hadn't told members that alterations to <img> were impossible. |
| 19:13 | <staydecent> | I'm guessing they went with "600w 200h" instead of "600x200" as to not be confused with the DPI declaration "2x" |
| 19:13 | <staydecent> | ? |
| 19:13 | <zcorpan> | the problem with MQ for the bandwidth/"load the page faster" use case is that the MQ describes a state of the UA, and the author needs to get the query "right", where it is easy to get the behavior backwards (like resulting in a lower resolution image when the user zooms *in*) |
| 19:14 | <MattWilcox> | staydecent: irrelevent. However you look at it that ties adaption to pixel units. Responsive designs do not use pixel units. |
| 19:14 | <annevk> | MattWilcox: where did Hixie say that though? |
| 19:14 | <MattWilcox> | annevk: there are a couple of people trying to find that out because it has been an accepted thing over there, brought up a few times. I've not found the original source yet. |
| 19:14 | <zcorpan> | whereas with the "dpi" syntax, the author just describes information about the image, and the user agent is free to decide which image it deems is most appropriate for the user given the environment (the browser is in a much better position to know this than the author) |
| 19:15 | <annevk> | MattWilcox: changing the parsing is impossible, adding attributes is not |
| 19:15 | <annevk> | MattWilcox: maybe there was some confusion about terminology there and what people understand as to what "parsing" means... |
| 19:15 | <MattWilcox> | See http://www.w3.org/community/respimg/common-questions-and-concerns/ and the section "What about modifying the behaviour of <img>?" |
| 19:16 | <annevk> | MattWilcox: yeah that seems about parsing |
| 19:16 | <annevk> | MattWilcox: with the "look ahead" remark |
| 19:16 | <ShaneHudson> | I agree that we have to be careful about changing <img> due to older (and current) browsers... but that does not mean we cannot touch it |
| 19:16 | <annevk> | MattWilcox: doesn't really mean you can't add new attributes, in fact, one of the proposals we have does so in a backwards compatible way |
| 19:17 | <staydecent> | MattWilcox: I don't understand, aren't you using pixel units in your proposal: http://mattwilcox.net/archive/entry/id/1082/ |
| 19:17 | <MattWilcox> | I'm sure there has been some misunderstanding about it, which is incredibly frustraiting. Browser vendor representitives were asked about it, and this is a major reason why editing <img> was ruled out. |
| 19:17 | <annevk> | Wilto: btw, it would be interesting to know who encouraged you to form a CG |
| 19:18 | <annevk> | Wilto: a CG is a fine place for discussion, but if parallel discussion happens in other groups there's no real guarantee you'll be heard unfortunately |
| 19:18 | <MattWilcox> | staydecent: I'm using CSS media. That example is pixels, but there is no reason at all why I couldn't have also used %, em, vh or anything else. |
| 19:19 | <staydecent> | ahh, so how could that flexibility be used in a html attr or element? |
| 19:19 | <ShaneHudson> | annevk: The CG was the first disccusion group/website I saw on the matter.. except blog psots of course |
| 19:19 | <MattWilcox> | staydecent: that's the brilliance of MQ. I used pixels in the example because it's easier for people to figure out than introducing stuff like vh or em which they may be less familiar with using in that way. |
| 19:20 | <annevk> | oh lol, that zeldman guy sure likes drama https://twitter.com/zeldman/status/201019688946384897 |
| 19:20 | <MattWilcox> | staydecent: we're proposing MQ syntax be added to HTML. That's how the <picture> tag works. There's nothing in my proposal that's different to the main <picture> one except I abstract the query away from the code block. |
| 19:20 | <ShaneHudson> | annevk: lol |
| 19:21 | <staydecent> | So, that syntax could be added to the <img set=""> attr? |
| 19:21 | <staydecent> | *if* one decided to take that route... |
| 19:21 | <MattWilcox> | I don't know. I can't see how the MQ syntax could be cleanly added into a singular attribute. |
| 19:21 | <ShaneHudson> | Who proposed set anyway? I have not yet seen anyone who has agreed with it, and I had not heard of it before today |
| 19:22 | <annevk> | Apple |
| 19:22 | <MattWilcox> | imgset was from someone at Apple |
| 19:22 | <ShaneHudson> | Ah, that explains it lol |
| 19:22 | <MattWilcox> | Intended for CSS, and now being pushed into HTML |
| 19:22 | <MattWilcox> | It's poor in both cases |
| 19:22 | <MattWilcox> | But less poor in CSS |
| 19:22 | <ShaneHudson> | yeah the css version I mostly agree with, but html I don't |
| 19:22 | <MattWilcox> | Still poor though. |
| 19:22 | <annevk> | I think it makes sense |
| 19:22 | <staydecent> | From what I;ve gothered today: <picture> element is easier to read and write for developers, but the implementation within browsers is more complex than the set attr.. |
| 19:23 | <MattWilcox> | staydecent: I'd agree with that summary. And I think that's not a problem. |
| 19:23 | <barnabywalters> | staydecent: that's my impression too |
| 19:23 | <zcorpan> | for the record, multiple attributes would be fine from the "impl complexity" perspective |
| 19:23 | <annevk> | for the case where you just want highres images <img src=lowres set="highres 2x"> is way easier than the alternative |
| 19:23 | <MattWilcox> | As I've said: vendors only have to worry about doing hard work once. But once it's in HTML, that's millions of people stuck with that syntax, for life. |
| 19:23 | <ShaneHudson> | Agreed, browser developers are very clever (as opposed to entry-level html) and it only needs to be implemented once |
| 19:23 | <MattWilcox> | annevk: of course it is, because it's far more targeted and far less useful. |
| 19:24 | <zcorpan> | MattWilcox: developers need to live with bugs in browsers |
| 19:24 | <MattWilcox> | annevk: you're not making a fair comparison really. |
| 19:24 | <annevk> | MattWilcox: did you see the extended version that also deals with width/height or is there some other use case? |
| 19:24 | <MattWilcox> | zcorpan: bugs get fixed. syntac doesn't. |
| 19:24 | <MattWilcox> | syntax |
| 19:24 | <annevk> | MattWilcox: well you have to consider what is going to be the common case and see how that compares |
| 19:25 | <MattWilcox> | annevk: so many other use cases! |
| 19:25 | <MattWilcox> | annevk: I know the common case, it's not retina. |
| 19:25 | <annevk> | MattWilcox: because trying to boil the ocean with a single feature generally does not work very well |
| 19:25 | <MattWilcox> | annevk: Other ways people wish to implement responsive images include... |
| 19:25 | <annevk> | see <object>, XML namespaces, ... |
| 19:26 | <MattWilcox> | annvek: ... NOT via pixels (layouts are often set in flexible units, and so are pictures) ... |
| 19:26 | <ShaneHudson> | Speaking of retina... does anyone know a good way to actually test retina without a device? |
| 19:26 | <annevk> | MattWilcox: yeah so just use SVG... |
| 19:26 | <MattWilcox> | annevk: ... and responding to screen size is only done because it's a proxy for bandwidth. MQ's are aiming to include bandwidth sensors too. And then <picture> can use them. |
| 19:27 | <annevk> | how would that work if you switch networks? |
| 19:27 | <barnabywalters> | MattWilcox: yes, one of the appeals (to me) of the <picture> element is it's extensibility |
| 19:28 | <MattWilcox> | annevk: SVG is not a raster format. Seriously, it is absolutely inapropriate for the majority of use cases. You can not SVG a photo. You can only SVG mathematically drawn images. |
| 19:28 | <shepazu> | SVG ALL THE THINGS!!!!! |
| 19:28 | <annevk> | MattWilcox: I guess I misunderstood what you meant by "NOT via pixels" |
| 19:28 | <zcorpan> | MattWilcox: as i've said, the browser is in a better position to know which image is appropriate (if it has information about the available images and their resolutions) than the author writing the MQ, even if MQ gets extended |
| 19:29 | <MattWilcox> | annvek: that's an implementation detail - but the browser has a recent connection it can query the real throughput on all the time - the last requested asset :) |
| 19:29 | <MattWilcox> | acorpan: No. The designer knows what is required to meet the requirements of the design. The browser does not. |
| 19:30 | <barnabywalters> | I'm off for the moment (going to sleep on it). Bye! |
| 19:30 | <MattWilcox> | Bye :) |
| 19:30 | <zcorpan> | MattWilcox: so you care about the adaptive layout use case, basically? not the "save bandwidth"/"load page faster" use case? |
| 19:30 | <staydecent> | zcorpan: Could developers avoid altering <picture><source> elms by listening to some Event? |
| 19:30 | <MattWilcox> | annvek: and yeah, I mean using pixel in a MQ is not actually recommended - most responsive designs are not based on pixels. But the assets that get served certainly are pixel based. |
| 19:31 | <annevk> | MattWilcox: the width/height proposal is not MQ based |
| 19:31 | <annevk> | which I think is a plus really, not all of MQ makes sense here |
| 19:31 | <MattWilcox> | zcorpan: I care about both, but the saving bandwidth is done via the design. Not via automated heuristics on the browser. |
| 19:31 | <annevk> | and putting bandwidth testing in MQ seems certainly way complicated to author |
| 19:31 | <zcorpan> | staydecent: browsers need to get the edge cases right even if developers could avoid it, because developers could also not avoid it, and on the web scale all edge cases will happen, and browsers must deal |
| 19:32 | <zcorpan> | MattWilcox: ok. MQ is appropriate for the layout use case. I'm arguing it is *not* appropriate for the bandwidth use case |
| 19:32 | <MattWilcox> | zcorpan: From the perspective of a designer the process goes like this: Detect the device size -> Design something to fit this device -> Implement this design as HTML/CSS/JS |
| 19:33 | <MattWilcox> | zcorpan: all the bits that we talk about are the last bits in the stack. It's thought about backwards a lot of the time, and we end up making the tools we have dictate the designs that are applied. It's the wrong way. |
| 19:33 | <staydecent> | zcorpan: I agree with that sentiment. But with my lack of knowledge, I find I often run into bugs in my scripts by not doing something in the right order or event. |
| 19:34 | <MattWilcox> | zcorpan: the design is the final experience. Everything else is tooling to achieve the design. |
| 19:34 | <MattWilcox> | zcorpan: and of course, a good design consideres the users context (device size, connection speed, etc). |
| 19:34 | <staydecent> | zcorpan: My point being, it's already part of my practice to make sure I do things with proper timing/within proper events. |
| 19:36 | <zcorpan> | staydecent: not sure i follow how this relates to the topic at hand :) |
| 19:36 | <jarek> | "SVG is not a raster format. Seriously, it is absolutely inapropriate for the majority of use cases. You can not SVG a photo." |
| 19:36 | <jarek> | in other words: SVG is suitable for all kinds of graphics on the web except photos |
| 19:36 | <staydecent> | zcorpan: RE: "browsers need to get the edge cases right even if developers could avoid it" |
| 19:37 | <jarek> | I mean gradients, buttons, icons, overlays - all this should be done with SVG, not bitmaps (as it is today) |
| 19:39 | <jarek> | it's sad that there are so many CSS3 fanboys, but nobody cares about SVG |
| 19:40 | <staydecent> | jarek: do you have any recommneded links/libraries/examples/tutorials for creating those elements with SVG? |
| 19:40 | <shepazu> | jarek: hey, I care about SVG! and I know 18 other people who do, too |
| 19:40 | <ShaneHudson> | Do you have any examples of using SVG for those? I must admit I focus much more on css and don't do much with svg |
| 19:40 | <MattWilcox> | Jarek: I have built websites for the last 8yrs, professionally, for various clients in various sectors with various companies. I can tell you that the vast majority of designed images are not achievable in SVG. |
| 19:40 | <shepazu> | MattWilcox: that seems like a pretty broad claim |
| 19:41 | <MattWilcox> | shepazu - look on some websites. Find me 5, just FIVE content images that are vectors. Now do the same but look for photo's. |
| 19:42 | <MattWilcox> | shepazu: remember we're talking content images here, not site-design elements, which are applied via CSS. We're on about HTML. So, it's stuff that clients add to sites in their CMS's. |
| 19:42 | <shepazu> | MattWilcox: http://yourlogicalfallacyis.com/burden-of-proof |
| 19:43 | <MattWilcox> | shepazu: oh grow up. |
| 19:43 | <jarek> | MattWilcox: with filter effects you can achieve most Photoshop effects |
| 19:43 | <shepazu> | MattWilcox: http://yourlogicalfallacyis.com/ad-hominem |
| 19:43 | <MattWilcox> | shepazu: it's not about effects. It's about content type. |
| 19:43 | <jarek> | MattWilcox: also, gradient meshes are on the roadmap which will allow as to create photo-realistic artworks |
| 19:43 | <shepazu> | MattWilcox: if it can be done in Illustrator, it can be done in SVG |
| 19:43 | <jamesr> | SVG is not useful for all icons/buttons/etc |
| 19:43 | <jarek> | staydecent: they problem with SVG is that we don't even have good authoring tools. Inkscape is a mess, Illustrator... :/ |
| 19:43 | <MattWilcox> | Yes, and most <img> content can not be donein illustraitor |
| 19:44 | <shepazu> | depends on your design aesthetic |
| 19:44 | <MattWilcox> | OK, have a look at all img's on the following websites: http://www.flickr.com/ |
| 19:44 | <MattWilcox> | http://en.wikipedia.org/wiki/Motor_racing#Motor_racing |
| 19:44 | <MattWilcox> | NOT DESIGN. Content. |
| 19:44 | <ShaneHudson> | shepazu: Design aesthetic has nothing to do with this at all... this is about use cases. SVG is brilliant for a few use cases but not for most |
| 19:44 | <MattWilcox> | We are doing CONTENT images. |
| 19:45 | <MattWilcox> | http://www.appliancesonline.co.uk/ |
| 19:45 | <MattWilcox> | http://dashes.com/anil/2011/07/if-your-websites-full-of-assholes-its-your-fault.html |
| 19:45 | <shepazu> | MattWilcox: nobody was claiming that you should do raster images in SVG, jarek mentioned gradients, buttons, icons, overlays, and other UI elements |
| 19:45 | <MattWilcox> | These are just some open tabs. |
| 19:45 | <MattWilcox> | Look at the <img> in them |
| 19:45 | <MattWilcox> | Almost none are possible in SVG |
| 19:46 | <staydecent> | MattWilcox: Your ponint makes sense. SVG is a red-herring in this discussion. |
| 19:46 | <jamesr> | and you frequently want different assets for icons at different resolutions (not just a simple scale up) |
| 19:46 | <MattWilcox> | UI elements are perfect places for SVG. But UI elements are defined in CSS - they are not embedded assets. |
| 19:46 | <MattWilcox> | Agreed. |
| 19:46 | <shepazu> | diagrams, charts, infographics, etc. are also great uses of SVG |
| 19:46 | <MattWilcox> | Those are not use cases applicable to the <img> tag, which is what we are discussing |
| 19:47 | <mdelcx> | hey all |
| 19:47 | <zcorpan> | jamesr: http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-allow-you-to-optimize-svg-icons-for-several-sizes |
| 19:47 | <shepazu> | MattWilcox: well, that's what you were discussing… Jarek brought up another topic that the rest of us were discussing |
| 19:47 | <MattWilcox> | Content images are <img> - the vast majority of all <img> throughout the web are added via some form of CMS, and are *not* vector based. |
| 19:47 | <ShaneHudson> | shepazu: diagrams etc are perfect for svg, and most people that know of svg know what it is good for |
| 19:48 | <shepazu> | and for <img> content that is a UI element, or is a digaram, chart, etc., SVG is reasonable for those use cases |
| 19:48 | <jarek> | yeah, I did not mean that there should be no support for responsive images |
| 19:49 | <MattWilcox> | To clarify: SVG is perfect for any vector. But you are not going to apply those as content images ( <img> ) 99% of the time, if only because you have to be a developer to know how to get them in. I don't know of any CMS that allows you to upload a vector image and that then outputs it *as* a vector. |
| 19:49 | <MattWilcox> | Agh, it's late and I must go! |
| 19:49 | <shepazu> | I strongly believe that we need a responsive image mechanism for rasters |
| 19:49 | <shepazu> | s/believe/agree/ |
| 19:49 | <MattWilcox> | I think everyone singing of the same sheet to be honest, bar small nuances that don't matter too much |
| 19:50 | <staydecent> | Must focus on work. Good discussion :) |
| 19:50 | <MattWilcox> | Cheers all for the conversation and viewpoints :) |
| 19:51 | <mdelcx> | I've been mulling this over today... has any thought been given to adding client "metadata" at the request level? |
| 19:52 | <mdelcx> | handling the serving of assets using the application, rather than repurposing media queries and modifying the markup |
| 19:52 | <mdelcx> | (in the client) |
| 19:53 | <mdelcx> | if the client added headers to every request, it would be a snap for the application to handle it |
| 19:53 | <zcorpan> | mdelcx: so basically conneg? |
| 19:54 | <zcorpan> | mdelcx: i think someone has considered it and written an email on whatwg explaining why it's a bad idea |
| 19:54 | <mdelcx> | zcorpan: i haven't been part of the conversation, so I'll have to take a look at that WG |
| 19:54 | <zcorpan> | mdelcx: basically, it would result in more overhead for all websites, even if only a small fraction would use the information |
| 19:55 | <zcorpan> | mdelcx: and it would increase finger printing |
| 19:55 | <adiabatic> | I hear there's a new proposed syntax for responsive images or similar from Hixie that Zeldman doesn't like much. Does anyone know offhand where it might be the whatwg list archives? I'm not exactly sure what I should be plugging into Google to find it |
| 19:55 | <mdelcx> | overhead, for sure |
| 19:56 | <mdelcx> | zcorpan: fingerprinting would depend on what the client had access to send |
| 19:56 | <mdelcx> | it shouldn't be any worse than a cookie |
| 19:57 | <zcorpan> | mdelcx: any new piece of information about the user increases finger printing |
| 19:57 | <zcorpan> | mdelcx: even if one piece isn't "worse" than a cookie, taken together they easily can identify a single user |
| 19:57 | <zcorpan> | mdelcx: we want to minimize it as much as possible |
| 19:57 | <mdelcx> | eh, I don't know if some client metadata and a cookie could identify a client |
| 19:58 | <mdelcx> | but i see you point for sure |
| 19:58 | <adiabatic> | Sure, but if you can piece together enough sufficiently weird client data… |
| 19:58 | <zcorpan> | cookie isn't the only thing there is today :-) |
| 19:58 | <mdelcx> | i know :) |
| 19:59 | <adiabatic> | Incidentally, is there a way to enumerate all the fonts that a user has on a system? I think I'm unique simply based on the fonts I have installed alone |
| 20:00 | <zcorpan> | adiabatic: you can't enumerate them, but you can list lots of fonts, try to apply them and measure the text width to see if the font was applied or not |
| 20:31 | <zcorpan> | i feel like it's time for a new #csspubquiz but i can't think of anything. maybe i should start with html quizzes instead |
| 20:39 | <benvie> | re: fonts that's not even falling back on flash which *will* give you a full list of fonts |
| 21:03 | <adiabatic> | benvie: heh, one more reason why I'm glad the only Flash I have on my system is bundled with Chrome |
| 21:06 | <zcorpan> | you're glad that flash is bundled with chrome? :-P |
| 21:47 | <benvie> | but yeah the amount of vectors towards making a UID for people are multitude =D |
| 21:57 | <annevk> | btw |
| 21:57 | <annevk> | a bunch of people submitted feedback as @ replies to @whatwg |
| 21:57 | <annevk> | dunno really what to do with those |
| 21:58 | <kennyluck> | sigh |
| 21:58 | <kennyluck> | j |
| 21:58 | <kennyluck> | ust |
| 21:58 | <annevk> | suggestions welcome, I'll get some sleep meanwhile |
| 21:58 | <kennyluck> | just count them as -1 to the current proposal |
| 21:59 | <annevk> | we don't care about that |
| 21:59 | <annevk> | this is not the IETF |
| 22:02 | <Wilto> | Some fledgeling developers might not be so familiar with IRC or mailing lists, but likely just wanted to be heard as well. |
| 22:02 | <Wilto> | I might not -1 them for trying to participate. Just saying. |
| 22:03 | <annevk> | Wilto: kennyluck was not saying that and I was not saying that either |
| 22:04 | <kennyluck> | I was saying that counting them is at least better than ignoring them at all. |
| 22:04 | <annevk> | Wilto: in particular I was asking for suggestions on how to deal with them, since we mostly use @WHATWG as a broadcast channel, we don't really have discussions over twitter with that account |
| 22:05 | <annevk> | kennyluck: but I was not suggesting to ignore them... |
| 22:05 | <annevk> | anyway, nn |
| 22:06 | <Wilto> | Oh, oh—voting against the _current_. My mistake, man. |
| 22:07 | <Wilto> | annevk: Totally redirect them to the CG. I tried to do that when people started a-bikesheddin' in here, too. |
| 22:08 | <kennyluck> | Wilto, yeah, that would work, I guess. |
| 22:08 | <gsnedders> | I guess a fair few of us use here to bikeshed in to avoid doing so on the mailing list :P |
| 22:10 | <Wilto> | It is the place for the community to get their discuss on—I mean, I don’t deny that it’s good to give people a forum in which to bikeshed to their little hearts' content. It's the internet, after all. |
| 22:11 | <kennyluck> | Wilto, I agree. We need more places like that for purely bikeshedding issues. |
| 22:11 | <Wilto> | I enjoy a good bikeshedding from time to time myself. Red, if anyone's wondering. |
| 22:11 | <kennyluck> | Fore |
| 22:11 | <kennyluck> | |
| 22:11 | <kennyluck> | |
| 22:11 | <kennyluck> | For |
| 22:11 | <kennyluck> | exm |
| 22:11 | <Wilto> | Yeah. It's like herding cats in there, but somebody's gotta do it. |
| 22:11 | <kennyluck> | For example, 'display: flex' vs. 'display: flexbox' for flex box is purely bikeshedding. |
| 22:12 | <kennyluck> | so are a lot of CSS stuff :p |
| 22:12 | <Wilto> | I vote `flexxx`, me. Sounds hip and edgy. |
| 22:12 | <Wilto> | Starring Vin Diesel. |
| 22:12 | <Wilto> | Okay, I'm getting punchy. You guys have a good weekend, yeah? |
| 22:13 | <kennyluck> | Wilto, you too. |
