| 00:08 | <zcorpan> | TabAtkins: time to flip a table? |
| 00:08 | <TabAtkins> | zcorpan: For fucks sake, yes. |
| 00:10 | <TabAtkins> | Oh, weird. If you @reply someone who doesn't exist, it doesn't count, and shows in other people's feeds anyway. |
| 00:11 | <TabAtkins> | In other words, for the purpose of showing/hiding @-replies, you're considered to follow all non-existent people. |
| 00:13 | <TabAtkins> | Shit, I keep ending tweets with periods. Gotta strip that shit. |
| 00:19 | <grigs> | TabAtkins: I *think* I may have finally figured out how to describe where I see the disconnect on the art direction side in the email I just sent to the list. I’m curious to hear what you think given our attempts earlier today to get on the same page. |
| 00:19 | <grigs> | TabAtkins: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035895.html |
| 00:22 | <tantek> | Good to see the progress on http://www.w3.org/wiki/Images |
| 00:22 | <tantek> | grigs - are the use-cases you mention, "art direction" vs "retina/bandwidth" adequately described / mentioned in that page? |
| 00:22 | <tantek> | grigs - are the use-cases you mention, "art direction" vs "retina/bandwidth" adequately described / mentioned in that page? |
| 00:22 | <tantek> | and uniquely enough to refer to by URL? |
| 00:23 | <grigs> | tantek: I don't think so. I was looking at that page earlier and trying to figure out where to start editing it. |
| 00:23 | <tantek> | hmm - list items make it harder to reference by frag - going to do some heading edits to make it more granular |
| 00:24 | <TabAtkins> | grigs: Answering your email now. You're misunderstanding the syntax, which may be causing the disagreement. |
| 00:24 | <grigs> | tantek: it isn't organized the way my brain works so i'm struggling a little to figure out how to contribute. not insurmountable, just giving me a moments pause (i opened it up to edit a few minutes ago and stopped) |
| 00:24 | <tantek> | grigs - let me take a shot |
| 00:24 | <othermaciej> | right now the wiki page seems more like a list of issues than of use cases |
| 00:25 | <grigs> | TabAtkins: Cool. |
| 00:25 | <grigs> | TabAtkins: Cool. |
| 00:25 | grigs | nods in agreement with othermaciej |
| 00:25 | <othermaciej> | "There are many different screen sizes" is not a use case, "authors want to serve different content to browsers with different viewport sizes, specifically like X, Y or Z" would be a use case |
| 00:32 | <tantek> | othermaciej - agreed - I'm on it |
| 00:33 | <grigs> | TabAtkins: hmm… so the width in srcset isn't the width of the image? but the "the algorithm here could be to sort the images by width, and remove all those that are wider than the available width" |
| 00:33 | <tantek> | grigs, othermaciej - take a look: http://www.w3.org/wiki/Images |
| 00:34 | <tantek> | Hopefully I've helped make it clearer what's missing in terms of documenting the use-cases |
| 00:34 | <grigs> | looks better. i'll take a stab later tonight. gotta head out soon. |
| 00:34 | <tantek> | thanks grigs - any incremental iteration / editing / contribution is appreciated |
| 00:34 | <zcorpan> | grigs: don't read the 507 thing. read the spec |
| 00:35 | <grigs> | zcorpan: i'm reading Hixie’s email. |
| 00:35 | <zcorpan> | ah. ok |
| 00:35 | <grigs> | zcorpan: not sure what the 507 thing is. URL for what I should read just to make sure I’m in the right spot? |
| 00:36 | <zcorpan> | i guess by "images" there, he really meant "candidates" |
| 00:36 | <tantek> | grigs - I think the "DPI" use-case is attempting to cover the "retina" use-case you mention: http://www.w3.org/wiki/Images#DPI |
| 00:36 | <tantek> | and the "slow networks" use case is attempting to cover the "bandwidth" use-case you mention: http://www.w3.org/wiki/Images#Slow_Networks |
| 00:36 | <tantek> | but I don't see anything that would correspond to the "art direction" use case you mention |
| 00:36 | <grigs> | correct |
| 00:37 | <tantek> | does that have to do with portrait vs. landscape? or something else? or both? |
| 00:37 | <grigs> | no, two things |
| 00:37 | <zcorpan> | grigs: it's just an extract from his email |
| 00:37 | <grigs> | first is easiest to explain here http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ |
| 00:37 | <grigs> | The Obama example in my post. |
| 00:39 | <tantek> | different cropping for different sizes? |
| 00:39 | <tantek> | is that what you mean by art direction? or are there other modifications going on? (different color palette, contrast, etc.) |
| 00:39 | <grigs> | The problem with the Obama example is that the photo doesn’t change proportions nor do I mention that the layout may change as well. In email, I looked at Nokia’s browser site as another example. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035795.html |
| 00:39 | <zcorpan> | if the image is *just* cropped, why isn't CSS crop good enough? |
| 00:40 | <tantek> | zcorpan - you beat me to it |
| 00:40 | <grigs> | zcorpan: downloading unnecessary data. |
| 00:40 | <grigs> | zcorpan: also, the nokia browser example shows the image making a more substantial change. |
| 00:40 | <zcorpan> | grigs: what if you have already downloaded the bigger image, and then the viewport gets narrower? |
| 00:41 | <grigs> | part of the reason why my Obama example was ok, but sort of misleading. |
| 00:41 | <grigs> | zcorpan: i'm not sure i understand the question. |
| 00:41 | <tantek> | a-ha, so the Obama example is the simple art direction use-case |
| 00:42 | <grigs> | tantek: right. very basic. |
| 00:42 | <tantek> | and the Nokia phone changing orientation (horizontal vs vertical) and crop is the more advanced art direction use-case |
| 00:43 | <zcorpan> | grigs: you said it would download unnecessary data. but going from a wide viewport to a narrow viewport would also download unnecessary data (a cropped image when you could just crop the bigger image you already have with css) |
| 00:44 | <grigs> | zcorpan: unnecessary data on a small screen--many of which can never be resized and thus will never see the extra data. |
| 00:45 | <tantek> | grigs, could you give your <h3> tags 'id' attributes so I could link directly to those sections here? http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ |
| 00:45 | <zcorpan> | grigs: mobiles can usually be flipped which changes the viewport width :-P |
| 00:46 | <zcorpan> | anyway, i shouldn't be here |
| 00:46 | <grigs> | tantek: done |
| 00:52 | <grigs> | heading out. i'll take a crack at the use cases wiki later. |
| 00:53 | <tantek> | ah just missed him. updated: http://www.w3.org/wiki/Images |
| 00:53 | <tantek> | for those interested in the "Art Direction" use-case, I attempted to capture what Grigs was explaining and emailing here: http://www.w3.org/wiki/Images#Art_Direction |
| 00:53 | <tantek> | I don't claim to have done it justice, please feel free to rewrite/extend what I'd written there to improve the use-case description. |
| 00:55 | <tantek> | also - if anyone wants to sort the use-cases by what they see as priority/importance (and add reasoning as to such), please feel free to re-order them - they're not in any particular order right now. |
| 01:40 | <Flakerimi> | Having <menu><ul><li></li></ul></menu> and styling with: menu { border:1em solid red} works, but is it wrong? I know its more xml but it helps. Creating custom tags should be treated as divs! |
| 01:41 | <Flakerimi> | So instead of creating <div id="wrapper"> why not just <wrapper> |
| 02:11 | <jmather> | TabAtkins: just a follow up thought re: bandwidth-based mq's… what if they're only calculated once per page load? That would prevent throwing assets out if something changes while a page loads up. |
| 02:27 | <zewt> | jmather: pages stay loaded for a long time now; bandwidth changes (wifi vs. cell vs. docked) |
| 02:28 | <jmather> | And that would be a problem for people loading large assets after-the-fact |
| 02:28 | <jmather> | ok, it's clicking now |
| 02:29 | <jmather> | Reading Dylan's reply to me on the CG |
| 02:29 | <jmather> | The problem is nothing really solves the core issue, as I understand it, because what we really need, for a future proof way to move forward, is a way to describe which image to select relative to the space available for it, as opposed to viewport size/whatnot |
| 02:30 | <jmather> | any other means of describing when to use which image means lots of headaches of one type or another come redesign time |
| 02:31 | <jmather> | and we can't do that because we don't know that until css is processed, which means we can't prefetch images |
| 02:31 | <jmather> | I'm sure i'm restating the obvious to a lot of people but it's just fully dawning on me :D |
| 02:31 | <tantek> | jmather - the use cases I've seen so far refer to device viewport dimensions, rather than "space available for it" |
| 02:32 | <tantek> | which use-case are you referring to? http://www.w3.org/wiki/Images |
| 02:33 | <jmather> | tantek: i'm not looking at any in particular. I'm processing in my head… the issue Dylan raises is how horrific the syntax can get, and what an unmaintainable nightmare it would become for static html when a redesign comes up |
| 02:34 | <tantek> | yeah, I haven't seen an "elegant" syntax solution yet either, nor am I sure what/which use-cases are solved by which. |
| 02:34 | <jmather> | and i started to reply that the media queries should describe how to display the image relative to the space available for it, which clicked the whole "we have to rely on the viewport, not the image space" deal, which lead me to the fact that none of this fits my personal distilled view of the problem. |
| 02:35 | <tantek> | indeed - I've found the best way to broaden our collective distilled views of the problem is to share/document the use-cases until there's some agreement there at least |
| 02:36 | <jmather> | I'm going to try to distill my use-case into the wiki and see if I can make something coherent |
| 02:36 | <tantek> | it's different from the existing use-cases? |
| 02:37 | <jmather> | essentially, when you redesign the site 4 years down the line, you shouldn't have to alter anything, because you have already described how to display the image for a variety of space considerations…. which I think invalidates every approach talked about thus far, but I could be wrong. |
| 02:37 | <jmather> | Is that off base or does that make sense? |
| 02:37 | <tantek> | jmather - I'm not sure any solution will handle the "redesign the site 4 years down the line" scenario |
| 02:37 | <tantek> | given how fast things are changing |
| 02:37 | <jmather> | because the goal of HTML5 was to begin to make things autonomous |
| 02:38 | <tantek> | it was? |
| 02:38 | <jmather> | part of it anyway |
| 02:38 | <jmather> | with <article> in particular |
| 02:38 | <tantek> | <article> essentially just reflected what we already knew from years of experience with RSS |
| 02:38 | <jmather> | should contain self-… something content, which can be pulled out and used elsewhere |
| 02:38 | <jmather> | right |
| 02:38 | <tantek> | nothing "future proof" there |
| 02:38 | <jmather> | but if you embed site-specific requirements on image displays inside an <article> |
| 02:38 | <tantek> | more like paving the footpaths |
| 02:39 | <jmather> | then that content is no longer container independent, so to speak |
| 02:39 | <jmather> | I take a little while to get myself to where my conclusion has taken me… give me a minute to rethink/rework/whatnot… :) |
| 02:41 | <jmather> | ok, let me try and re-step-through that logic set |
| 02:42 | <jmather> | theoretically, content wrapped in an <article> tag should be able to be taken off the site and used elsewhere w/ limited issues. Am I right-ish here? |
| 02:43 | <tantek> | as much as RSS <item>s can be, I suppose. |
| 02:46 | <jmather> | so, if we're embedding rules on when to use what image, there would be a valid concern in ensuring the rules described when to pick which image relative to the image's container. Because if the rules described how to select an image based on browser viewport, that would/could cause an issue where it's loading the 800px wide image when the container is only … ok, well, i guess … now i've gone and circled myself back around to where |
| 02:46 | <jmather> | ago |
| 02:47 | <jmather> | what if picture had a default style of max-width: 100%? It still doesn't solve the bigger than intended, but it should keep it from looking absolutely horrible in almost every situation... |
| 02:48 | <jmather> | it'd be hard to apply that to img w/ backwards compatibility issues, so it wouldn't work for srcset (I don't think) |
| 02:50 | <jmather> | I still think the best idea would be to be able to describe relative to container width, but I think it's been established as not going to happen, so I don't know at this point. :D |
| 02:52 | <tantek> | jmather - I'm having trouble following your general example. if you could describe it with a specific example similar to http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/#artdirection that would help |
| 02:54 | <jmather> | Yeah… let me think on it to see if I can solidify it. It's hard for me to think it through at the moment though because I am pretty sure srcset initially tried/thought to do this and it got shot down by the browsers, so the width/height then became relative to viewport instead of container. |
| 02:59 | <TabAtkins_> | jmather: The maintenance issue is unavoidable if you want to do this in HTML proper. And you *do* want that, because it allows prefetching. |
| 03:00 | <jmather> | TabAtkins_: right, except maybe it'd be worth giving up prefetching to gain a longer lifetime of usefulness. |
| 03:03 | <jmather> | Just a thought, because, well, I like thinking about crazy things. |
| 03:06 | <jmather> | Most of the page will use image-set in CSS to load the layout and such, so the only things affected are content images anyway |
| 03:06 | <jmather> | eventually anyway |
| 03:09 | <jmather> | I'm just trying to maybe throw some off-the-wall ideas out there. If these are crackpot ideas, feel free to tell me so. I just know a lot of the time people sometimes get stuck thinking inside of some constraints, and so I like to try and see if they can be re-evaluated. |
| 03:10 | jmather | has a team who is good at making him readjust outside of the box. |
| 03:14 | <tantek> | jmather - no problem with posing off-the-wall/crackpot ideas for exploration/discussion, especially when framed as such. |
| 03:15 | <jmather> | tantek: cool. I'm just thinking from my perspective… there's not enough man-power in the world at my employer to go back and upgrade 4 year old content. |
| 03:15 | <jmather> | well, there is, but not that will get paid for. |
| 03:16 | <jmather> | It'd be a miserable summer for a couple interns. |
| 03:16 | <tantek> | othermaciej - earlier http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2032 you asked (and I missed amongst other discussion) "what bad advice do you think the respimg guys got on the whatwg mailing list?" |
| 03:16 | <jmather> | And I hate having that be the solution to anything |
| 03:16 | <tantek> | and the answer was/is: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0169.html |
| 03:17 | <tantek> | jmather, designing for "future proof" is pretty much impossible (if you figure this out, plenty of folks want to hear about it) |
| 03:17 | <tantek> | however, designing for "future friendly" may be possible |
| 03:18 | <jmather> | tantek: i'd be happy with friendly, but i don't think any of the responsive solutions even hit that target very squarely |
| 03:18 | <jmather> | unless i'm wrong about srcset's implementation, which i very well could be |
| 03:18 | <jmather> | (that the width/height refer to browser, not container) |
| 03:19 | <tantek> | jmather, I leave you with http://futurefriend.ly/ - and note that many of the folks behind that were/are involved with the respimg CG (and some have even been participating right here in the channel today) |
| 03:20 | <jmather> | Yeah, I know |
| 03:20 | <jmather> | I've been there and all |
| 03:20 | <jmather> | I'm just saying, looking at it as a whole, selecting the content image to display based on browser size, is a terrible idea. |
| 03:21 | <jmather> | Well, terrible implementation anyway |
| 03:27 | <jmather> | Is that too off the wall, or does that make sense? |
| 03:31 | <jmather> | Just realized I hadn't actually joined the CG group so I can't post my crazy idea. Maybe that's a good thing, but request pending anyway… :D |
| 03:34 | <tantek> | jmather - anyone with a W3C account can edit the W3C wiki: w3.org/wiki |
| 03:35 | <tantek> | no need to wait to join the CG or anything else |
| 03:36 | <jmather> | I figured I would use the CG to ensure I'm not a total moron before I let /everyone/ know I'm an idiot, and I don't think the wiki is the right context for a 'what if we are looking at the wrong requirements' type question |
| 03:37 | <jmather> | Maybe they've already thought of this and it's simply so un-doable that they've dismissed it |
| 03:40 | <jmather> | Alright, off for the night. Good chat, thanks for dealing with my crazy. Hopefully tomorrow will be more cohesive. |
| 03:42 | <tantek> | jmather - if you follow the example of describing a specific use-case like the URL I gave earlier, http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/#artdirection then it's unlikely that you'll appear as a moron/idiot ;) |
| 03:42 | <jmather> | Brain hurts from all this today, heh |
| 03:42 | <tantek> | welcome back grigs |
| 03:42 | <tantek> | w3.org/wiki/Images edited per our discussion here earlier |
| 03:42 | <jmather> | tantek: yeah, that's the plan. It's pretty off the wall though, so I think I'll have to put on my flame retardant underwear before I post it. |
| 03:43 | <grigs> | thanks tantek. :-) |
| 03:44 | <grigs> | jmather: fwiw, i think i've been following your logic and i don't think you're off the wall. |
| 03:44 | <jmather> | grigs: I've got an even more crackpot idea at this point, unless you've been watching in chat for the last hour or so? :D |
| 03:45 | <grigs> | jmather: i just reread the chat logs before jumping back in. |
| 03:45 | <jmather> | Ah! awesome |
| 03:45 | <grigs> | little easier to catch up on the conversation tonight than it was earlier in the day. |
| 03:45 | <jmather> | Yeah, I bet |
| 03:46 | <jmather> | I'll think on it over night, but the more I think about it, the more I think the premise of our solutions in general have been wrong. The images should be selected based on the size of the content area available. I know that means it can't be selected until css has been processed, but maybe that's just something we accept as part of the solution to get the best solution. |
| 03:50 | <jmather> | I have to run for a few |
| 03:50 | <jmather> | bbl |
| 03:50 | <grigs> | tantek: the write up of art direction is good |
| 04:00 | <tantek> | thanks grigs |
| 04:03 | <grigs> | btw, this slide deck from bryan rieger was one of the first examinations i saw of this issue. http://www.slideshare.net/bryanrieger/prime-sky in particular, slide 20 shows the scaling issues. |
| 04:03 | <grigs> | was tempted to add it to the use cases wiki, but think it might confuse things because it was written before responsive design was a thing. |
| 05:15 | <AryehGregor> | annevk, subscribe to the Mozilla bug and you'll know as much about detach() as I do. If anyone complains, it will likely be filed as blocking that bug, so we'll see it then. |
| 05:15 | <AryehGregor> | The metrics I added are actually useless in practice. I should have added something that counts how many times an exception would have been thrown and now wasn't. |
| 06:47 | <hsivonen> | I should probably read all the threads before commenting, but it seems that the responsive images debate conflates two issues: |
| 06:47 | <hsivonen> | 1) Whether it's better to have <picture> and <source> or an attribute-based microsyntax |
| 06:48 | <hsivonen> | 2) Whether Media Queries are the appropriate way to declare things that pertain to the selection of the alternative image files |
| 06:49 | <othermaciej> | those are two of the differences between <picture> and <img srcset> |
| 06:49 | <othermaciej> | I believe there is at least one other important difference: |
| 06:50 | <othermaciej> | 3) Should selecting an image intended for a particular display resolution automatically rescale it, or should it be up to the author to do that with CSS? |
| 06:50 | <othermaciej> | and one other difference the importance of which has not been established: |
| 06:50 | <othermaciej> | 4) Are there useful criteria for selecting images besides width, height, and pixel density? |
| 06:51 | <othermaciej> | those are the actual non-bikeshed differences between the two options |
| 06:51 | <hsivonen> | othermaciej: about #3: do you mean it's up for debate if the box of the image should change size relative to the surroundings as part of the responsiveness function? |
| 06:51 | <hsivonen> | othermaciej: yeah, #4 is part of #2 |
| 06:51 | <othermaciej> | hsivonen: I'm not sure I understand the framing of your question, but... |
| 06:52 | <hsivonen> | othermaciej: I'm not sure what you mean by not automatically rescaling |
| 06:52 | <othermaciej> | let's say I have a 600x200 version of an image and a 1200x400 version of an image, the latter intended for devices with a 2x scale factor (e.g. an iPad with Retina display) |
| 06:53 | <othermaciej> | the following always has the same intrinsic size: <img src="foo.jpg" srcset="foo⊙2 2x"> |
| 06:53 | <hsivonen> | so if I have a device with 1.5 scale factor, I'd expect to see the 1200x400 version scaled down |
| 06:54 | <othermaciej> | the following does not always have the same intrinsic size: <picture><source src="foo⊙2" media="min-device-pixel-ratio: 2"><source src="foo.jpg"></picture> |
| 06:54 | <hsivonen> | also, if I have an 1x device and zoom in by a factor of 2, I'd expect to see the 1200x400 image as soon as it has downloaded |
| 06:54 | <othermaciej> | the <picture> version will have different intrinsic size based on which image is selected |
| 06:54 | <hsivonen> | ah |
| 06:55 | <hsivonen> | that would be bad for swapping the images when zooming |
| 06:55 | <othermaciej> | the <img> version will have consistent intrinsic size, as when the 2x version is selected, it gets downscaled by a factor of 2 |
| 06:55 | <othermaciej> | you'd have to either apply fixed size, or have a CSS rule that applies image-resolution based on a media query |
| 06:55 | <othermaciej> | with the <picture> version |
| 06:56 | <othermaciej> | otherwise, you get something twice as large, not something with twice the density |
| 06:59 | <hsivonen> | I don't particularly like responding to issues by rallying troops from one's group of colleagues or fans instead of addressing *why* something is better or worse |
| 07:00 | <othermaciej> | me neither |
| 07:00 | <othermaciej> | I think the important thing to do is identify use cases (or other pragmatic considerations) in favor of one approach or the other, rather than counting Facebook likes |
| 07:01 | <othermaciej> | (or their equivalent) |
| 07:01 | <smaug____> | hmm, how to say politely that "given its quality, this spec sure feels like an early draft" |
| 07:01 | <othermaciej> | smaug____: what formal maturity level is it? |
| 07:02 | <smaug____> | WD |
| 07:02 | <othermaciej> | for an FPWD, the polite way to say it would be to not mention it, since it goes without saying |
| 07:02 | <othermaciej> | for a PR, presumably even stronger words are called for |
| 07:02 | <othermaciej> | for LCWD, the way you said it is probably appropriately polite |
| 07:03 | <smaug____> | well, I'd want to answer to comment " This is not an early draft of a spec." |
| 07:03 | <smaug____> | ah, yeah, I could just say it is WD |
| 07:12 | <anatolbroder> | othermaciej: any feedback on srcset from devs of Wordpress, Drupal, Joomla, $anotherCMS? I’m wondering which CMS will be the first to implement it. |
| 07:14 | <othermaciej> | anatolbroder: no idea; haven't heard from any of them |
| 07:15 | <othermaciej> | I doubt it will get big-time deployment until at least one significant-share browser supports it |
| 07:17 | <anatolbroder> | othermaciej: I suppose, Webkit will support it very soon (<6 month), right? |
| 07:18 | <othermaciej> | I hope so - depends on how fancy we want to get |
| 07:19 | <hsivonen> | anatolbroder: I sure hope no CMS deploys anything on the responsive images topic before there's a browser build to test with |
| 07:19 | <hsivonen> | premature and subtly incorrect deployment in a popular CMS is a way to poison a feature for everyone |
| 07:26 | <anatolbroder> | hsivonen: sure. But I hope the guys from the popular CMSs pay attention to that topic. If $cms_1 supports responsive images before $cms_2, I would start my next cat’ face project with $cms_1. |
| 07:33 | <jgraham> | see also: premature polyfills |
| 07:35 | <Von_Davidicus> | Yes, it's me again, with questions of markup. <: ) |
| 07:35 | <othermaciej> | it's better to polyfill only once there's something to fill |
| 07:35 | <jgraham> | Right. Making the whole wall out of polyfill is likely to be structurally unsound, or something. |
| 07:36 | <jgraham> | Although I think that's not quite the right extension of the metaphor |
| 07:36 | <Von_Davidicus> | How often were webpages written in XML + XSLT? |
| 07:36 | <jgraham> | It's more like "will get in the way of building the actual wall" |
| 07:36 | <jgraham> | Von_Davidicus: I doubt anyone has statistics. Is "too often" too cynical? |
| 07:38 | <Von_Davidicus> | So I'm not the only one who was that weird? |
| 07:38 | <jgraham> | Von_Davidicus: It depends whether you were responsible for http://thedailywtf.com/Articles/Where-the-Wild-Web-Things-Are.aspx or not |
| 07:39 | <hsivonen> | Von_Davidicus: often enough that removing support for XSLT is not actively pursued but rarely enough that it doesn't make sense to invest in improving XSLT support |
| 07:40 | <Von_Davidicus> | Okay. |
| 07:40 | <Von_Davidicus> | Okay. |
| 07:40 | <jgraham> | Oh, that was quite a good answer |
| 07:40 | <hsivonen> | there's even at least one Chrome Experiment that uses XSLT. For shame. |
| 07:41 | <jgraham> | Although I think it is the same as "too often" |
| 07:41 | Von_Davidicus | did most of a website in XSLT + XML (+ Schema + DTD + WTHWIT) and another set of pages with XML + XSLT. |
| 07:41 | Von_Davidicus | did most of a website in XSLT + XML (+ Schema + DTD + WTHWIT) and another set of pages with XML + XSLT. |
| 07:41 | <anatolbroder> | What’s about Firefox and Opera, are they willing to support the srcset soon (<6 month)? |
| 07:41 | <Von_Davidicus> | But I wasn't going to count those because that would be cheating. |
| 07:42 | <jgraham> | anatolbroder: We (Opera) don't generally make promises about our roadmap. |
| 07:42 | <hsivonen> | anatolbroder: it would be unwise for anyone to promise support at this point |
| 07:43 | <jgraham> | anatolbroder: A reasonable point is that a simpler design is likely to lead to faster implementations |
| 07:43 | <Von_Davidicus> | Here's another question: What's wrong with XML + XSLT? |
| 07:43 | <anatolbroder> | jgraham, hsivonen: I understand. |
| 07:44 | <jgraham> | If the feature needs extensive development + QA work it will take longer than if one bored developer can do it in an afternoon |
| 07:44 | <tantek> | FWIW server-side XSLT is used some production deployments. |
| 07:44 | <tantek> | *in some |
| 07:44 | <hsivonen> | yeah, the parts of srcset that would fall on my plate to implement would be simpler than the parts of <picture> that would fall on my plate |
| 07:44 | <hsivonen> | server-side XSLT is OK |
| 07:44 | <tantek> | hsivonen - it's still a pain to maintain. |
| 07:44 | <jgraham> | (I am not claiming that any design is simple enough to only be an afternoon of work) |
| 07:45 | <tantek> | but once it works, it seems quite reliable. |
| 07:45 | <Von_Davidicus> | But--and here's the reason I used it--It resulted in a smaller website (pertaining to file size) |
| 07:48 | <othermaciej> | serving xml+xslt to the client has some downsides |
| 07:48 | <Ms2ger> | Wow |
| 07:48 | <othermaciej> | 1) you have to transform the whole document before you can render it |
| 07:48 | <Ms2ger> | Is there anything I should read in the million lines of Responsive Images trolling in yesterday's logs? |
| 07:49 | <othermaciej> | 2) you can't really do dynamic updates to your model very well and have them properly restyled (as with css0 |
| 07:49 | <jgraham> | Ms2ger: I think you will livwe |
| 07:49 | <jgraham> | *live |
| 07:49 | <othermaciej> | 3) if you are using generic xml or a custom xml vocabulary with your xslt, you are serving something that doesn't have useful widely understood semantics for data mining type consumers |
| 07:50 | <othermaciej> | so, less efficient to render, less dynamically adaptable, and less semantic |
| 07:50 | <othermaciej> | using xslt on the server side does not have any of these issues |
| 07:50 | <othermaciej> | assuming your output is html |
| 07:50 | <anatolbroder> | jgraham: I see the point. I really love the scrset spec. It’s so smart. This is the solution I always dreamed of. Now I can tell, the web is not print anymore. I build my current picture based project with scrset in mind. Thanks again to all you devs! |
| 07:51 | <Ms2ger> | anatolbroder, are you a webdev? |
| 07:51 | <Von_Davidicus> | Okay, so 1) means that the pages actually load slower than an HTML page? |
| 07:51 | <hsivonen> | Von_Davidicus: yes |
| 07:52 | <anatolbroder> | Ms2ger: I create web pages. |
| 07:52 | <Von_Davidicus> | Wow. |
| 07:52 | <hsivonen> | 4) XSLT doesn't benefit from speculative preloading of images, scripts and CSS |
| 07:52 | <Von_Davidicus> | Could you explain 2) a bit more clearly? |
| 07:52 | <Ms2ger> | That can't be true, several people came in here yesterday and made it clear that ALL web developers HATE srcset |
| 07:54 | <othermaciej> | Von_Davidicus: 2) is relevant only if you have client-side scripts or ever plan to add any |
| 07:55 | <Von_Davidicus> | Oh, okay. None of my XML+XSLT pages had any scripts--certainly none that fiddled with the DOM. |
| 07:56 | <anatolbroder> | Ms2ger: It was very funny, indeed. Most of that “web developers” are control freaks, caught in the print world. They just don’t want to understand, what is web for. |
| 07:56 | <Ms2ger> | anatolbroder, I'm not going to comment on that :) |
| 07:58 | <Von_Davidicus> | Assuming the DOM is what you were referring to when you said "model" and stuff like "document.createElement()" was what you meant by doing "dynamic updates". :) |
| 07:58 | <Von_Davidicus> | Assuming the DOM is what you were referring to when you said "model" and stuff like "document.createElement()" was what you meant by doing "dynamic updates". :) |
| 08:06 | <Ms2ger> | tantek, note, regardless of whether you want to call Hixie a benevolent dictator, you know he's not appointed for life. |
| 08:06 | <Ms2ger> | tantek, note, regardless of whether you want to call Hixie a benevolent dictator, you know he's not appointed for life. |
| 08:09 | <tantek> | Ms2ger - I don't think any of the BFDLs referenced in the Wikipedia article are "appointed for life" - from my understanding it is a deliberate term of exaggeration. |
| 08:09 | <tantek> | sorry, BDFLs |
| 08:18 | <Ms2ger> | Also, winter/summer on http://wiki.whatwg.org/wiki/Irc-people ... Northern or Southern hemisphere? |
| 08:20 | <charlvn_> | very good question, but is daylight savings going to make so much of a difference in any case? |
| 08:20 | <charlvn_> | we're talking about an hour sooner or later |
| 08:20 | <charlvn_> | most people's irc times are pretty variable in any case |
| 08:22 | <tantek> | charlvn_ on the contrary, the data shows most people's irc times are pretty consistent within certain blocks of hours - see the preponderance of particular color blocks for people in general here: http://gavinsharp.com/irc/whatwg.html |
| 08:22 | <Gargoyle> | If you were going to specify a timezone, what is wrong with the "Europe/London" syntax? |
| 08:22 | <tantek> | Gargoyle - because that's political, you can't trust it over time. |
| 08:22 | <zcorpan> | TabAtkins: for the square and rectangle example, if you wanted to use the rectangle as the fallback image, the syntax doesn't provide for that, right? |
| 08:23 | <tantek> | Ms2ger - by the preponderance of people listed there it is easy to conclude Northern hemisphere. If you have suggestions for clarifying, please feel free to edit the wiki accordingly. |
| 08:24 | <charlvn> | tantek: i guess you might be right |
| 08:24 | <charlvn> | perhaps it's just my own times that are quite variable :) |
| 08:24 | <tantek> | charlvn - it's not about me, I'm simply communicating what the data appears to show. feel free to provide alternate interpretations. |
| 08:24 | <Gargoyle> | tantek: Isn't that a benefit, so you don't need to wory about DST? |
| 08:24 | <Ms2ger> | tantek, how so? Europe/London seems more reliable than +0000 |
| 08:24 | <othermaciej> | what is the purpose of the people/timezone list? knowing when to try to contact someone? |
| 08:25 | <Ms2ger> | I guess one is more likely to move than to have their time zone changed under them... |
| 08:25 | <tantek> | othermaciej - I don't remember why it was introduced to the list of irc-people on microformats.org - but given it's presence there I simply copied the template rather than re-bikeshed it. |
| 08:25 | <tantek> | its presence even |
| 08:25 | <tantek> | feel free to edit the template if you have ideas for improving it |
| 08:26 | <tantek> | Ms2ger - named timezones are the parlance of politicians and tend to be less stable than numerical offsets from Z which is more the parlance of scientists. |
| 08:27 | <tantek> | borders change, when summer times start/end change etc. |
| 08:27 | <hsivonen> | tantek: looking at the recent i18n comments on HTML, it seems the political instability of named time zones is considered a feature |
| 08:27 | <Ms2ger> | tantek, well, I guess Europe/London wouldn't make much sense if you were in Lisbon, but it seems sensible enough for someone who actually lives in London |
| 08:27 | <tantek> | hsivonen, that's sad to hear. |
| 08:27 | <othermaciej> | tantek: what is the intended purpose of the irc-people list in general? would be glad to improve it if I knew what it is meant to be used for |
| 08:28 | <othermaciej> | hsivonen: oh? |
| 08:28 | <tantek> | help people get to know each other better |
| 08:28 | <tantek> | help people get to know each other better |
| 08:28 | <hsivonen> | tantek: it seems they want to be able to specify named time zones so that if the politicians move the named zone, the times anchored to the named zone change accordingly |
| 08:28 | <Gargoyle> | tantek: Is'nt that what whois is for? |
| 08:29 | <tantek> | whois doesn't do irc nickname lookups AFAIK |
| 08:29 | <hsivonen> | (if that's not what they want, asking for named zones makes no sense) |
| 08:29 | <tantek> | plus a wiki makes it possible for anyone to curate such information about anyone |
| 08:30 | <tantek> | othermaciej - with so many folks in the channel, it helps to be able to lookup who is a person, what have they worked on, are they a browser implementer etc. - especially should a person choose to document that on their User page. |
| 08:30 | <hsivonen> | I suppose the use case is that if you agree that a meeting takes place at noon on a given day next year, if the politicians change the UTC offset, the meeting still takes place at noon according to the new offset |
| 08:30 | <tantek> | the breadth of participants has far exceeded a small # of folks who mostly know each other. |
| 08:30 | <tantek> | the breadth of participants has far exceeded a small # of folks who mostly know each other. |
| 08:31 | <othermaciej> | ok, so not just list of nicks but ideally some sort of brief information about their context-relevant background and interests |
| 08:31 | <tantek> | othermaciej - the "brief information about their context-relevant background and interests" can go on their User page - it's already there for that purpose |
| 08:31 | <tantek> | better to just have the list link to user pages |
| 08:31 | <tantek> | rather than duplicate that content inline |
| 08:31 | <tantek> | rather than duplicate that content inline |
| 08:31 | <othermaciej> | is it considered bad form to edit someone else's user page? |
| 08:32 | <tantek> | othermaciej - nah, people are assume to be benevolent on a wiki until proven otherwise |
| 08:32 | <tantek> | it's part of the wiki-way (as far as I understand it) |
| 08:32 | <tantek> | it's part of the wiki-way (as far as I understand it) |
| 08:32 | <hsivonen> | (I think politicians who think it's cool to have daylight saving time and non-integral hour time zones should be required to implement calendar software with some punishment for each bug) |
| 08:32 | <Ms2ger> | Depends on the wiki, I've been told off for it long ago |
| 08:32 | <tantek> | hsivonen +1 |
| 08:32 | <tantek> | hsivonen +1 |
| 08:32 | <othermaciej> | I've fixed enough security vulnerabilities to consider everyone malevolent by default, myself included :-) |
| 08:32 | <Ms2ger> | othermaciej++ |
| 08:32 | <tantek> | Ms2ger - yeah? sorry to hear that. haven't had that problem with any wiki I've edited. |
| 08:33 | <othermaciej> | I had the impression that user pages, unlike general wiki content, were in some way "owned" by the relevant user |
| 08:33 | <othermaciej> | but I am no expert on wiki etiquette |
| 08:33 | <charlvn> | the irc regulars list sounds like an interesting idea, but while we are on the topic of the wiki, it seems like i am both unable to perform password recovery and unable to register a new account |
| 08:33 | <tantek> | othermaciej - mostly it's summed up by be nice and forgiving. |
| 08:34 | <tantek> | that tends to handle the vast majority of cases. |
| 08:34 | <tantek> | beyond that, wikipedia has various escalations for conflict resolution. |
| 08:35 | <tantek> | charlvn - new whatwg wiki accounts are registered thru Hixie. |
| 08:35 | <othermaciej> | I'm totally down with being nice to and forgiving of wiki edits made by others, just not sure what kinds of edits it is nice to make |
| 08:35 | <odinho> | 09:36 < othermaciej> it's better to polyfill only once there's something to fill <-- BTW totally agreed, -- I made my proof of concept (very shortcutty) polyfill merely to demonstrate that "it can't be polyfilled!11" argument was incorrect. |
| 08:35 | <annevk> | charlvn: if you give me your email address I can get you an account |
| 08:35 | <othermaciej> | I will take your word for it that editing other people's user pages is provisionally ok unless the person in question says otherwise |
| 08:35 | <charlvn> | tantek: thanks, just saw the notice on the main page as well, i'll speak to him next time i see him online or just send him a mail |
| 08:35 | <tantek> | othermaciej - perhaps the kinds of edits you wouldn't mind if someone else made for you? |
| 08:36 | <tantek> | btw anyone who'd like to discuss political timezone arcana should ping dbaron when he's around - he's got the most thorough database of historical timezone changes (nearly weekly?) that I've seen. |
| 08:38 | <othermaciej> | wikipedia has a lot of policy related to their use of user pages http://en.wikipedia.org/wiki/User_page |
| 08:38 | <AryehGregor> | Wikipedia convention is definitely that you should generally avoid touching other people's user pages unless you have very good reason. |
| 08:39 | <AryehGregor> | I've corrected typos and formatting errors and gotten away with it, and I had people do things like substitute templates that were about to be deleted. |
| 08:39 | <othermaciej> | man, wikipedia has more policies than the html wg |
| 08:39 | <AryehGregor> | And of course, if you violate policies . . . |
| 08:39 | <AryehGregor> | othermaciej, Wikipedia is a lot bigger than the HTMLWG. |
| 08:39 | <AryehGregor> | Also, its "policies" are whatever someone happens to have decided to write, and half the time they're ignored. |
| 08:40 | <tantek> | othermaciej - their policies show a history of the abuses they've had to deal with |
| 08:40 | <AryehGregor> | Real and perceived. |
| 08:40 | <tantek> | not unlike other processes I know of. ahe. |
| 08:40 | <tantek> | *ahem |
| 08:40 | <charlvn> | yeah considering the number of people who edit the whatwg wiki is fairly small, i don't see this as a big problem in the short-mid term |
| 08:40 | <charlvn> | i'm sure if there are some specific cases of abuse/unhappiness we can get them resolved fairly easily |
| 08:40 | <tantek> | oh look - I totally missed that the Astrology company withdrew their copyright suit over the Olson timezone database: http://www.computerworld.com/s/article/9224557/Astrolabe_withdraws_copyright_suit_over_Internet_time_zone_database |
| 08:40 | <tantek> | well that was hilarious while it lasted. |
| 08:41 | <othermaciej> | html wg policy has grown cumulatively in response to real or perceived problems with events that actually occurred |
| 08:41 | <hsivonen> | othermaciej: unfortunately, the policy hasn't been very good at adapting to deal with problems arising from the policy |
| 08:41 | <othermaciej> | I think it could be potentially improved by having less of it |
| 08:42 | <tantek> | othermaciej - I wonder if there is a way to grow processes in a more usable/accessible/positive manner. that is, instead of so much focus on avoiding negative events/behavior, can we craft process to presume positive / cooperative behaviors, and then separately list "exception handling" so that it doesn't interfere with understanding the main process flow of control. |
| 08:42 | <tantek> | othermaciej - I wonder if there is a way to grow processes in a more usable/accessible/positive manner. that is, instead of so much focus on avoiding negative events/behavior, can we craft process to presume positive / cooperative behaviors, and then separately list "exception handling" so that it doesn't interfere with understanding the main process flow of control. |
| 08:43 | <othermaciej> | it is hard to design a system that cannot be gamed (as a general rule) |
| 08:43 | <hsivonen> | I think the HTML WG policy optimizes for avoidance of accusation of the chairs being unfair but I think it should optimize for good technical outcomes and efficient use of the participants' time |
| 08:43 | <tantek> | indeed |
| 08:43 | <othermaciej> | tantek: I originally envisioned the issue process in general, and the survey part in particular, to be "exception handling" |
| 08:43 | <othermaciej> | but that created an incentive for some people to purposefully fall into the exception case |
| 08:43 | <tantek> | in practice it appears to have descended into a primary use |
| 08:43 | <tantek> | I'm not sure there is incentive, as much as inaction |
| 08:44 | <othermaciej> | because there is no incentive not to |
| 08:44 | <othermaciej> | because there is no incentive not to |
| 08:44 | <tantek> | it seems if people disagree, and do nothing, surveys happen |
| 08:44 | <othermaciej> | at least, if you care a lot about a narrow set of issues |
| 08:44 | <othermaciej> | at least, if you care a lot about a narrow set of issues |
| 08:44 | <tantek> | but I don't have a specific proposed fix, so I can't really criticize particulars |
| 08:45 | <tantek> | hence my more general musing above |
| 08:45 | <othermaciej> | I prefer systems that give people positive incentives to do the right thing |
| 08:46 | <othermaciej> | sometimes negative incentives to discourage undesirable behavior are also required but ideally should not be the focus |
| 08:46 | <othermaciej> | sometimes negative incentives to discourage undesirable behavior are also required but ideally should not be the focus |
| 08:52 | <hsivonen> | so typical. I'm trying to fix one document.open() regression and notice that the code doesn't appear to quite match the spec in other cases, either |
| 08:52 | <hsivonen> | sigh. instead of just adding a couple of boolean checks, it seems I now have to write test cases |
| 08:54 | <zcorpan> | hsivonen: the real fun doesn't start until you find that the spec is wrong :-P |
| 09:06 | <AryehGregor> | hsivonen, is writing test cases a bad thing? |
| 09:06 | <AryehGregor> | :) |
| 09:38 | <odinho> | Oh my. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035920.html |
| 09:42 | <annevk> | classic |
| 10:04 | <hsivonen> | it's rather hard to get a good idea of how srcset works conceptually by reading the algorithms in the spec. :-( |
| 10:05 | <annevk> | there's a note that explains it except it has minimum/maximum reversed |
| 10:07 | <hsivonen> | oh ok. so srcset doesn't do what I thought it was doing. |
| 10:07 | <hsivonen> | seems to just reinvent viewport querying |
| 10:07 | <hsivonen> | instead of declaring the characteristics of the image |
| 10:08 | <hsivonen> | now I don't understand the point of doing srcset instead of <source media> |
| 10:08 | <annevk> | the 2x bit is not querying |
| 10:08 | <annevk> | well, Xx bit |
| 10:09 | <hsivonen> | did Hixie post to the list with design rationale? |
| 10:10 | <annevk> | hsivonen: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html |
| 10:11 | <hsivonen> | annevk: thanks |
| 10:13 | <jgraham> | hsivonen: testharness.js testcases + W3C submission please? :) |
| 10:14 | <hsivonen> | jgraham: is testharness.js still hard to use? |
| 10:14 | <jgraham> | hsivonen: It really isn't that hard to use |
| 10:14 | <jgraham> | If you mean "is it Mochitest" then no |
| 10:15 | <hsivonen> | I don't want mochitest. I want something that I can run in all browsers and then mochitestify |
| 10:16 | <jgraham> | Well testharness.js tests run in all browsers |
| 10:16 | <jgraham> | For a sutiable definition of "all" |
| 10:17 | <smaug____> | mochitests should run on all browsers if you don't use browser specific features |
| 10:17 | <smaug____> | the problem is to set proxies correctly in the browsers |
| 10:25 | <odinho> | testharness.js is nice. I like it alot. Being grown up with testharness I see lots of weaknesses in other systems when I have to use them. |
| 10:48 | <jgraham> | So, can anyone suggest what the simplest thing I can do is to cause a task to be queued? Preferably not involving resource loading |
| 10:49 | <annevk> | setTimeout |
| 10:49 | <jgraham> | Not good enough since that has a delay |
| 10:50 | <annevk> | jgraham: if you specify 0 it shouldn't |
| 10:50 | <jgraham> | (if setTimeout 0 was sure to not have a delay it would be) |
| 10:50 | <jgraham> | Well I can try that, but the spec doesn't actually say it has to work |
| 10:50 | <odinho> | It has no delay first time called? Isn't there an optimization like that? -- Yeah, spec... |
| 10:50 | <jgraham> | So if there is a better option, I would prefer it |
| 10:51 | <jgraham> | odinho: "Optionally wait a User Agent specified amount of time" or something |
| 10:51 | <odinho> | jgraham: IndexedDB transaction? :P |
| 10:52 | <jgraham> | odinho: No :p |
| 10:55 | <zcorpan> | jgraham: postMessage |
| 10:56 | <hsivonen> | soo... does "completely loaded" mean something other than readyState == "complete"? http://www.whatwg.org/specs/web-apps/current-work/#completely-loaded |
| 10:57 | <jgraham> | zcorpan: Wrong task source |
| 10:57 | <hsivonen> | apparently so |
| 10:57 | <hsivonen> | gotta love terminology like that |
| 10:57 | <annevk> | hmm, so even the ALA article from yesterday on <picture> gets the media query syntax wrong |
| 10:58 | <hsivonen> | I wonder how Gecko tracks the "completely loaded" concept |
| 10:58 | <wilhelm> | annevk: Is there a spec somewhere? I haven't paid attention. |
| 10:58 | <annevk> | wilhelm: there's a spec for media queries |
| 10:58 | <odinho> | wilhelm: For what? srcset? |
| 10:59 | <wilhelm> | odinho: Yes. Or <picture>. Or whatever it's called now. (c: |
| 10:59 | <odinho> | wilhelm: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset |
| 11:00 | <annevk> | beautiful, all the examples on https://github.com/Wilto/respimg are also invalid |
| 11:00 | <annevk> | you'd think if you propose using media queries you'd at least know how to use them |
| 11:00 | <hsivonen> | Hixie: is it intentional that per spec document.open() doesn't return document when the steps are terminated due to the user refusing to allow the document to be unloaded? |
| 11:01 | <zcorpan> | jgraham: which task source do you need? |
| 11:02 | <wilhelm> | odinho: Thanks. |
| 11:02 | <jgraham> | zcorpan: The one that is used for the task related to the load event |
| 11:03 | <jgraham> | DOM manipulation |
| 11:03 | <zcorpan> | annevk: i think being grumpy doesn't help |
| 11:04 | <jgraham> | There is so much grumpy going round that not even dglazkov can balance it out |
| 11:04 | <zcorpan> | jgraham: window load? |
| 11:04 | <jgraham> | Yeah |
| 11:04 | <zcorpan> | yeah there is, and clearly it doesn't help |
| 11:05 | zcorpan | opens "The End" |
| 11:06 | <hsivonen> | ha. at least Gecko isn't randomly non-compliant. It's consistent with IE: http://hsivonen.iki.fi/test/moz/document-open-during-network-parse.html |
| 11:06 | <hsivonen> | Gecko and Trident don't return document from document.open() contrary to the spec |
| 11:06 | <hsivonen> | WebKit and Presto return document per spec |
| 11:09 | <zcorpan> | jgraham: have a syntax error in a dedicated worker and listen for worker.onerror |
| 11:09 | <zcorpan> | though that loads a resource too eh |
| 11:10 | <zcorpan> | jgraham: <input autofocus> |
| 11:11 | <hsivonen> | hmm. the spec seems bogus in this case: http://hsivonen.iki.fi/test/moz/document-open-during-script-created-parse.html |
| 11:12 | <zcorpan> | jgraham: or the storage event |
| 11:12 | <hsivonen> | never trust the spec |
| 11:12 | <hsivonen> | always write test cases anyway |
| 11:12 | <hsivonen> | sigh |
| 11:13 | <zcorpan> | jgraham: or use <marquee> |
| 11:13 | <jgraham> | marquee?! |
| 11:13 | <zcorpan> | yep |
| 11:14 | <zcorpan> | the start event |
| 11:14 | <zcorpan> | and finish |
| 11:15 | <jgraham> | Wow |
| 11:15 | <jgraham> | Every day's an adventure in HTML land |
| 11:16 | <jgraham> | That looks perfect, and delightfully bizzare. Thank you! |
| 11:16 | <zcorpan> | np |
| 11:46 | <zcorpan> | odinho: isn't this the wrong way around? |
| 11:46 | <zcorpan> | <img src="fallback..." srcset="logo-150px.jpg, logo-50px.jpg 600w"> |
| 11:46 | <odinho> | zcorpan: img without anything will get Infinite w and Infinite h. |
| 11:46 | <zcorpan> | logo-50px.jpg will be used when the viewport is 600px or *bigger* |
| 11:47 | <zcorpan> | also you need at least one descriptor, or the comma will be part of the url |
| 11:49 | <zcorpan> | so it should be <img src="fallback..." srcset="logo-150px.jpg 600w, logo-50px.jpg 1x"> or <img src="logo-50px.jpg" srcset="logo-150px.jpg 600w"> |
| 11:49 | <odinho> | zcorpan: Ah, very true. |
| 11:50 | <zcorpan> | (the syntax doesn't support the case where you want to use the 150 image as the fallback, afaict) |
| 11:50 | <zcorpan> | maybe there should be an attribute to give descriptors for the src attribute |
| 11:51 | <zcorpan> | or have a max-width descriptor |
| 11:51 | <odinho> | zcorpan: I did rock around that one a few times also, wondering if I should write something correct or just small and easy and only to the point. But yes, it'd be all wrong. Anyway, that is written wrong, but it can be done like I say anyway. Just look past the error :P |
| 11:52 | <odinho> | zcorpan: I don't understand. |
| 11:52 | <odinho> | zcorpan: I think it can support anything as fallback. |
| 11:52 | <zcorpan> | the fallback is a candidate, but you can't change its descriptors |
| 11:53 | <zcorpan> | let's say you want to have 600w for the fallback |
| 11:54 | <zcorpan> | having two candidates with the same descriptors is invalid |
| 11:54 | <zcorpan> | (so <img src="fallback..." srcset="logo-150px.jpg 600w, logo-50px.jpg 1x"> is invalid actually) |
| 11:55 | <zcorpan> | (since fallback... and logo-50px.jpg have the same descriptors) |
| 11:55 | <odinho> | Hmm. Either you or I am wrong here. srcset="logo-150px.jpg 600w, logo-50px.jpg 1x", I would've written srcset="logo-150px.jpg 1x, logo-50px.jpg 600w". |
| 11:55 | <odinho> | zcorpan: I don't see why that is valuable. |
| 11:57 | <odinho> | The attribute essentially takes a comma-separated list of URLs each with one or more descriptors giving the maximum viewport dimensions and pixel density allowed to use the image. |
| 11:57 | <odinho> | </quote> from spec. |
| 11:57 | <odinho> | ... To specify an image, give first a URL, then one or more descriptors of the form 100w, 100h, or 2x, where "100w" means "maximum viewport width of 100 CSS pixels", |
| 11:58 | <zcorpan> | "If there are any entries in candidates that have an associated width that is greater than max width, then remove them," |
| 11:59 | <zcorpan> | so if the viewport is 400px, the 600w candidate is removed |
| 11:59 | <odinho> | That's conflicting. |
| 11:59 | <zcorpan> | odinho: what you quoted might be wrong :-) |
| 11:59 | <odinho> | Yes, or the steps in the algorithm might be. :P |
| 12:00 | <zcorpan> | Hixie: ^ |
| 12:00 | <hsivonen> | maybe we should have the <picture><source> thing for the "art directed" axis and srcset="foo.jpg 2x" for the different pixel samplings of the same image |
| 12:00 | <odinho> | hsivonen: Or punt, art directed. As I want. |
| 12:00 | <odinho> | hsivonen: Have a way to say "don't do prefetch load" maybe. -- So that it can be done in javascript. |
| 12:00 | <zcorpan> | what's clear with the current syntax is that even people who read the spec get it wrong |
| 12:00 | <zcorpan> | that's bad |
| 12:01 | <zcorpan> | at least the width/height descriptors |
| 12:01 | <hsivonen> | zcorpan: yeah. it can't stay in the spec as written |
| 12:01 | <hsivonen> | It's terribly confusing that Nw and Mh don't refer to the image file's characteristics |
| 12:02 | <zcorpan> | yes |
| 12:02 | <zcorpan> | and even if you know it refers to the viewport, it's not clear if it's max-width or min-width |
| 12:03 | <hsivonen> | that, too |
| 12:05 | <odinho> | zcorpan: Hmmmm. Yeah, now I wonder more, what is supposed to be correct - the detailed spec, or the overview... |
| 12:05 | <odinho> | zcorpan: I'll go back to the source. |
| 12:07 | <odinho> | <img alt="Obama spoke at the factory." src="factory.jpeg" srcset="obama-factory-face.jpeg 500w"> |
| 12:08 | <odinho> | If viewport 1000px. factory Infinity is greater than 1000. So that one is removed. |
| 12:08 | <odinho> | The spec algorithm steps are reversed/wrong then. Based on Hixie's example in his email. |
| 12:09 | <zcorpan> | i'll fire off an email |
| 12:10 | <odinho> | This one: If there are any entries in candidates that have an associated width that is greater than max width, then remove them, unless that would remove all the entries, in which case remove only the entries whose associated width is greater than the smallest such width. |
| 12:10 | <odinho> | Should probably say "associated width that is less than max width". (or less than or the same, or similar). |
| 12:11 | <odinho> | As far as I've understood it. |
| 12:13 | <jgraham> | It has to be min width |
| 12:14 | <jgraham> | Uh, have I confused myself |
| 12:15 | <jgraham> | Well I guess it could work either way, depending on what you want the behaviour of src to be |
| 12:15 | <jgraham> | The important point is that it should be one or the other though |
| 12:15 | <jgraham> | So you can't create gaps |
| 12:16 | <jgraham> | So yeah, maybe a slightly more verbose syntax would help |
| 12:17 | <odinho> | zcorpan: I strongly believe it should be min-width, and that was the intended thing, that only the spec steps got it wrong. |
| 12:17 | <jgraham> | odinho: I thought the opposite. Why do you strongly believe that? |
| 12:18 | <odinho> | jgraham: Because of all the code hixie has been giving makes sense when it is that, all code I've written assumes that as well. |
| 12:18 | <zcorpan> | odinho: you mean max-width? :) |
| 12:18 | <jgraham> | It's probably clearer not to talk in terms of media query properties |
| 12:18 | <odinho> | zcorpan: I mean, steps should say "associated width that is less than max width". |
| 12:18 | <odinho> | zcorpan: I don't know if that is min- og max- tbh :P |
| 12:19 | <odinho> | yeah probably max when you say it like that. |
| 12:19 | <odinho> | Oh man |
| 12:19 | <jgraham> | odinho: Do you think that an image with 600w shoud load if the viewport is wider than 600px or narrower, given sutiable alaternatives? |
| 12:20 | <odinho> | jgraham: 600w, it picks that picture if the viewport is 600 or less. |
| 12:20 | <jgraham> | And you think that is the right behaviour? |
| 12:20 | <jgraham> | (I agree that is what the spec says, and I agree it makes sense) |
| 12:21 | <jgraham> | Because it means that the @src image is always the biggest one |
| 12:21 | <jgraham> | Which seems like the right fallback behaviour |
| 12:21 | <zcorpan> | (except it's not what the spec says in the algorithm) |
| 12:22 | <odinho> | And that's our confusion ;-) |
| 12:23 | <jgraham> | It's not? |
| 12:24 | <odinho> | jgraham: Nope. Spec is contradicting itself in the overview-text, and the actual steps. As far as me an zcorpan has been able to see. |
| 12:24 | <zcorpan> | http://krijnhoetmer.nl/irc-logs/whatwg/20120516#l-1182 |
| 12:24 | <annevk> | there's a bug on the note already |
| 12:24 | <jgraham> | If the viewport is narrower than the width descriptor, you remove the image from the list of candidates |
| 12:25 | jgraham | isn't looking at the note |
| 12:25 | <jgraham> | it's in green -> irrelevant :) |
| 12:25 | <odinho> | annevk: Shouldn't be a bug on the note, should be in the steps. IMHO. |
| 12:25 | <odinho> | annevk: But the bug goes for the same anyway ;-) |
| 12:26 | <odinho> | annevk: Where is it? |
| 12:26 | <jgraham> | ...which doesn't match what you expect |
| 12:26 | <jgraham> | OK |
| 12:34 | <annevk> | odinho: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17057 |
| 12:35 | <smaug____> | ++foolip_ |
| 12:39 | <annevk> | smaug____: context? |
| 12:41 | <smaug____> | annevk: reviewing a badly defined spec |
| 12:41 | <smaug____> | (WebAudio) |
| 12:50 | <adactio> | I'm glad it's not just me who was confused by what's in the spec. |
| 12:54 | <adactio> | Also, this text in the spec is very presumptuous: " This attribute allows authors to provide alternative images for environments with smaller screens..." It could equally well be used to provide alternative images for environments with *larger* screens (in fact, using the "Mobile First" approach, it should be). |
| 12:55 | <odinho> | adactio: Heh, don't get too worked up over that. ;-) |
| 12:56 | <adactio> | odinho: I'm not getting worked up. I'm just pointing out an unwarranted assumption in the spec text. |
| 12:57 | <Kolombiken> | Better? " This attribute allows authors to provide alternative images for different screens in different environments…" |
| 12:57 | <Kolombiken> | No assumptions |
| 12:57 | <odinho> | adactio: It's only explanation text (non-normative), it's not "real" part of the spec. |
| 12:57 | <odinho> | Kolombiken: Yeah. |
| 12:57 | <foolip_> | smaug____, you rang? |
| 12:57 | <adactio> | I thought that non-normative text was in green. |
| 12:58 | <adactio> | Kolumbiken: Your rewording sounds good. |
| 12:58 | <odinho> | adactio: I didn't actually check where it was, just sounded super non-normative. |
| 12:58 | <adactio> | odinho: That was why I brought it up: I would expect to see use-case sentences like that in the non-normative text. |
| 12:58 | <Kolombiken> | adactio: Thanks :) |
| 12:59 | <odinho> | adactio: Ah, ohwell. It's easy to fix. |
| 12:59 | <slikts> | is this the what what in the butt group? |
| 12:59 | <odinho> | Kolombiken: It doesn't speak about different screen sizes, or different pixel densities though. |
| 13:01 | <Philip`> | adactio: Anything that isn't phrased with "must"/"should"/etc, and that isn't a definition used by such phrases, is non-normative regardless of typography |
| 13:01 | <Kolombiken> | odinho: Which one doesn't? |
| 13:01 | <adactio> | Philip: Okay. Got it. |
| 13:01 | <jgraham> | The sentence seems right per spec. The img @src will always be used on infinitley big screens and the srcset allows you to provide images for smaller screens |
| 13:02 | <odinho> | jgraham: Ah, that's very true. |
| 13:02 | <Philip`> | adactio: (according to http://ln.hixie.ch/?start=1140242962&count=1) |
| 13:02 | <jgraham> | There is some confusion about whether this is what is intended, but it is a statement of fact |
| 13:02 | <jgraham> | i.e. neither normative nor non-normative |
| 13:02 | <jgraham> | well strictly non-normative |
| 13:02 | <jgraham> | But different to a note |
| 13:06 | <adactio> | So the example in the spec is wrong, no? srcset="banner-phone.jpeg 100w" will be served up to every device with a viewport width greater than 100 pixels, over-riding the image in the src attribute (where the intention was to only serve it up to small screens). So src="banner-phone.jpeg" srcset="banner.jpg 100w" would actually be correct. |
| 13:07 | <odinho> | adactio: Nope, opposite. |
| 13:07 | <odinho> | adactio: Although you've hit the bug we've been talking about. :-) |
| 13:07 | <jgraham> | adactio: The spec is buggy at the moment |
| 13:07 | <adactio> | odinho: That is *extremely* worrying. |
| 13:07 | <odinho> | adactio: Because the spec says two things about that right now. |
| 13:07 | <jgraham> | There is no point in discussing this until the spec bug is fixed |
| 13:08 | <adactio> | So is the plan to effectively make it impossible to mobile-first development? |
| 13:08 | <odinho> | adactio: Nope. |
| 13:09 | <odinho> | <img src="mobile-first.jpg" srcset="mobile-first.jpg 400w, normal.jpg 1000w, supersizemeomg 4069w"> |
| 13:09 | Ms2ger | yawns |
| 13:09 | <odinho> | adactio: granted, if you have a bigger screen than 4069px now, you'll get the mobile image :P -- But you can set it very high if you want. |
| 13:10 | <adactio> | That. Sucks. |
| 13:10 | <adactio> | Seriously. That's fucking awful. |
| 13:10 | <Ms2ger> | Yes |
| 13:10 | <Ms2ger> | Did you miss the part where there is a spec bug? |
| 13:10 | <Ms2ger> | Did you also miss the idea that bugs can get fixed? |
| 13:11 | <odinho> | Well, I want that behaviour I said now. |
| 13:11 | <adactio> | Ms2ger: But this isn't about the spec bug, this about the desired behaviour. |
| 13:12 | <Ms2ger> | Go and send a polite comment to the whatwg list, then |
| 13:12 | <adactio> | Ms2ger: The spec bug will get resolved to make it clearer what the intended use is. And the intended use is desktop-first. |
| 13:12 | <adactio> | Ms2ger: Oh, I plan to. |
| 13:14 | <Lachy> | gsnedders, Ms2ger, in Anolis, how do I get the --dump-xrefs argument to work? It seems to just hang when I try running: $ anolis --dump-xrefs=data/xrefs/output.json Overview.html |
| 13:14 | <jgraham> | I don't understand foo-first |
| 13:14 | <jgraham> | It's src-first |
| 13:15 | <wingo> | greets |
| 13:16 | <adactio> | jgraham: It's a question of whether you assume a large-screen environment by default (in the src attribute) that gets over-ridden for small-screen environments (in the srcset attribute) vs. assuming a small-screen environment by default (in the src attribute) which gets over-ridden for large-screen environments (in the srcset attribute). |
| 13:16 | <wingo> | are there html5lib folks here? where do I send a patch? |
| 13:16 | <adactio> | It sounds like the plan is to go with an assumption of large-screen. That is very, very troubling. |
| 13:17 | <jgraham> | adactio: Rather than talking about "the plan" being "very very troubling" why not send technical feedback on how the existing solution has a problem meeting your usecase, phrased in a polite way that doesn't assume a conspiracy to screw you over? |
| 13:18 | <adactio> | jgraham: I'm writing an email right now. And I didn't say anything about conspiracies. |
| 13:18 | <adactio> | jgraham: Physician, heal thyself. |
| 13:19 | <jgraham> | wingo: Yes. Attach it to an issue, perhaps? |
| 13:19 | <adactio> | jgraham: And what wording should I use rather than "the plan"? "desired behaviour"? Seriously, I'd like to know. |
| 13:20 | <Ms2ger> | Lachy, does data/xrefs/output.json exist? |
| 13:21 | <jgraham> | adactio: "The srcset draft" |
| 13:21 | <Lachy> | no, should I create it first? |
| 13:21 | <Ms2ger> | Yes |
| 13:21 | <Ms2ger> | On which revision are you? |
| 13:21 | <Lachy> | empty file or with something in it? |
| 13:21 | <adactio> | jgraham: That describes the thing, not the intention. |
| 13:21 | <Lachy> | anolis --version says 1.2pre |
| 13:21 | <jgraham> | adactio: Yes. |
| 13:22 | <Ms2ger> | { "url": "foo#" } |
| 13:22 | <Lachy> | and I just updated html5lib to the most recent version too 0.95 |
| 13:22 | <wingo> | jgraham: ah, hum; just mailed it to the list |
| 13:22 | <wingo> | issue is probably better |
| 13:22 | <Ms2ger> | Lachy, well, it's the HG changeset I'm looking for :) |
| 13:22 | <wingo> | modulo the obligatory grumbling about google accounts :) |
| 13:22 | <adactio> | jgraham: I need a phrase to describe the approach that "the srcset draft" is taking. The approach. The plan. The desired behaviour. |
| 13:22 | <jgraham> | adactio: No you don't |
| 13:23 | <bjankord> | Yeah he does |
| 13:23 | <adactio> | jgraham: Yes, I do. |
| 13:23 | <bjankord> | We all do |
| 13:23 | <jgraham> | You need to explain how the current draft fails to meet your use case |
| 13:23 | <adactio> | jgraham: Okay. Finally. |
| 13:24 | <bjankord> | With srcset, if the viewport width changes will the img src change? |
| 13:25 | <Lachy> | Ms2ger, ok, well, I should have the most recent changes. I downloaded and installed a fresh copy from the repo yesterday. |
| 13:25 | <Ms2ger> | Ah, hmm |
| 13:25 | <Ms2ger> | Because that version should have a useful error message... |
| 13:25 | <Lachy> | anyway, even after creating the json file, I get the same result. It just sits there doing nothing until I kill it a few minutes later with Ctrl-C |
| 13:26 | <wingo> | jgraham: http://code.google.com/p/html5lib/issues/detail?id=205 |
| 13:27 | <jgraham> | wingo: Oh, nice, thanks! |
| 13:27 | <Ms2ger> | Oh |
| 13:28 | <wingo> | you're welcome :) |
| 13:28 | <Lachy> | it also seems to make no difference regardless of which input file I use, whether I use Overview.src.html or Overview.html. I even tried using a copy of the whatwg spec. |
| 13:28 | <Ms2ger> | Lachy, you need something like anolis --dump-xrefs=data/xrefs/output.json Overview.src.html /tmp/foo |
| 13:29 | <Lachy> | what's the /tmp/foo path for? |
| 13:29 | <bjankord> | ... With srcset, if the viewport width changes, will the img src update? |
| 13:30 | <bjankord> | For example, with the following markup: <img alt="The Breakfast Combo" |
| 13:30 | <bjankord> | src="photo-mobile-portrait.jpeg" |
| 13:30 | <bjankord> | srcset="photo-mobile-portrait.jpeg 320w, photo-mobile-landscape.jpeg 480w"> |
| 13:30 | <Lachy> | oh, I see. It needs an output file. |
| 13:30 | <Ms2ger> | Yeah |
| 13:30 | <bjankord> | Would the img element update to use the photo-mobile-landscape on orientation change from portrait to landscape? |
| 13:31 | <Ms2ger> | I guess I can probably make it work without one, but I'm not sure how much refactoring it would need |
| 13:31 | <samuelfine> | bjankord: That's a good question. Not sure of the answer, but it makes me wonder how the browser will handle loading or pre-loading those srcset images. |
| 13:32 | <samuelfine> | bjankord: If the src does update, will there be a FOUC-esque load of the new image? Etc. |
| 13:32 | <Lachy> | thank you. |
| 13:32 | <bjankord> | I believe preloading/prefetching is a valid concern, one that sould be considered in any solution. |
| 13:33 | <Ms2ger> | I've made it throw an exception for now |
| 13:33 | <bjankord> | As far as FOUC, there are some JS based solutions that swap out images in the src attribute that do not seem to have noticeable FOUC |
| 13:34 | <odinho> | bjankord: If you read the spec, you'll find the section where the algorithm for updating is. |
| 13:34 | <odinho> | bjankord: It is specced, but browsers doesn't *have* to do it when the environment changes. But they are free to do so. |
| 13:35 | <odinho> | bjankord: So a desktop browser will most probably do it. -- Whilst a phone might opt to save the bandwidth required to do a new fetch. |
| 13:35 | <bjankord> | Ah I see |
| 13:35 | <bjankord> | Yeah I'm reading through - http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset |
| 13:36 | <odinho> | bjankord: The algorithms are a bit further down. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates and then scroll down the full first algorithm, down to: "The user agent may at any time run the following algorithm to update an img element's image in order to react to changes in the environment. (User agents are not required to ever run this algorithm.)" |
| 13:37 | <bjankord> | odinho: Thanks! |
| 13:39 | <samuelfine> | Yes, thanks odinho. Looks like FOUC shouldn't be an issue, images aren't replaced until new images are fully downloaded. |
| 13:40 | <odinho> | samuelfine: But it might flash over to the new image. If it doesn't fade-between or something. Guess that's QoI (Quality of Implementation), something user agents can compete on to make look nice. |
| 13:42 | <samuelfine> | odinho: I would hope browsers would drop in new images over old ones before removing, but you're right. Up to the implementers to decide. |
| 13:43 | <bjankord> | samuelfine: That does sounds like the best way to handle the image swap, if/when it happens. |
| 13:43 | <odinho> | samuelfine: Oh, I think noone would leave a gap inbetween! It's possible yes, but why would you? :P I was thinking about just doing a fast swap, or a swap with a 0.2s dissolve between the images. |
| 13:45 | <samuelfine> | I try to avoid assuming any browser will default to the Right Way. ;) |
| 13:46 | <zewt> | dear world: please stop starting your own threads when we have 8 already for the same topic |
| 13:48 | <wingo> | jgraham: http://code.google.com/p/html5lib/issues/detail?id=206 as well |
| 13:48 | <odinho> | zewt: Haha. Yeah. |
| 13:48 | <wingo> | i was going to make planet venus add preload=none to all videos, but it seems not so straightforward |
| 14:01 | <Ms2ger> | Oh look, Gecko supports <source media> now |
| 14:02 | <odinho> | Ms2ger: Hehe. |
| 14:03 | <Ms2ger> | I bet Opera did it first |
| 14:04 | <odinho> | Ms2ger: ^^ How much? |
| 14:04 | <odinho> | :P |
| 14:04 | <Ms2ger> | Hmm? |
| 14:06 | <odinho> | Ms2ger: Choke up the money, lad ;] |
| 14:06 | <Ms2ger> | Oh, heh |
| 14:06 | <Ms2ger> | 10000 dollars? ;) |
| 14:07 | <odinho> | Okay! :D I'll go in on that oone. |
| 14:07 | Ms2ger | is secretly running for US president |
| 14:11 | <zcorpan> | opera indeed did do it first :-) |
| 14:11 | <zcorpan> | but now i want to drop it :-P |
| 14:13 | <Ms2ger> | Too late ;) |
| 14:13 | <odinho> | WAT! |
| 14:13 | <odinho> | I didn't know we had done it. |
| 14:14 | <odinho> | Ms2ger: Good thing it was Monopoly dollars! Now I just need your address to send it to you. |
| 14:14 | <odinho> | :P |
| 14:14 | <Ms2ger> | Hah |
| 14:17 | <zcorpan> | odinho: we've supported it from the start (10.50) |
| 14:18 | <odinho> | zcorpan: Yeah, saw that now. Way before my time. |
| 14:19 | <Ms2ger> | Newb ;) |
| 14:19 | <odinho> | :( |
| 14:20 | <odinho> | :D |
| 14:20 | <odinho> | (I just couldn't let that negative hang there...) |
| 14:20 | <Ms2ger> | http://xkcd.com/859/ |
| 14:21 | <odinho> | Ms2ger: Yeah, it does feel bad. |
| 14:33 | <zcorpan> | odinho: gotta love when someone top-post replies to your email asking not to top-post |
| 14:36 | <odinho> | zcorpan: lol, haven't seen it yet. |
| 14:36 | <odinho> | zcorpan: It may be like a "I really hate you" |
| 14:37 | <zcorpan> | you replied to it, so you must have seen it :-P |
| 14:39 | <odinho> | zcorpan: Oh, I forgot that one. I asked for a new one now. And Matt did inline reply then. And Mike Taylor answered him with the guidelines, -- and then Matt answered back with a top-post. Which was kinda funny. :P |
| 14:40 | <odinho> | zcorpan: Oh, -- yes, I also asked for non-top-posting in the email *before* that. |
| 14:40 | <zcorpan> | yeah |
| 14:52 | <zcorpan> | step 6 "If url is empty, then jump to the step labeled descriptor parser." - if url is empty, doesn't that mean that you have reached the end of the attribute value? |
| 14:57 | <annevk> | zcorpan: just means you hit some space characters |
| 14:57 | <annevk> | well one |
| 15:05 | <zcorpan> | julian's concern with the comma seems valid. what can we use instead? newline? |
| 15:06 | <zcorpan> | the examples seem to use newline anyway for readability |
| 15:06 | <hober> | newline is way worse than comma |
| 15:06 | <zcorpan> | why? |
| 15:07 | <annevk> | what's wrong with comma? |
| 15:07 | <jgraham> | Newline is awful |
| 15:07 | <zcorpan> | annevk: urls can contain comma |
| 15:08 | <ShaneHudson> | newline is fine for presentation but remember it will often be minimised |
| 15:08 | <annevk> | zcorpan: sure |
| 15:08 | <ShaneHudson> | Use comma but add a new line as syntax style rather than syntax itself |
| 15:15 | <hober> | the comma comes after the scale factor, which isn't a url, and before the next url. if you think your urls might start with a comma, use whitespace. |
| 15:17 | <zcorpan> | hober: i've seen one example where the descriptors were all omitted. that's invalid, sure, but it doesn't mean that the current syntax is golden |
| 15:20 | <jgraham> | Should have used JSON in the attribute value. srcset = "[{'url':'foo.jpg', 'height':200, width:20, resolution:2}]" everyone loves JSON |
| 15:20 | <jgraham> | Note: this was not a serious suggestion |
| 15:20 | <hober> | zcorpan: indeed. i believe i listed "new microsyntax" as a drawback of the design in my proposal :) |
| 15:20 | <smaug____> | annevk: so, if a new event interface doesn't have init*Event, should one be able to create such event using createEvent() ? |
| 15:21 | <annevk> | as per spec yes |
| 15:21 | <zcorpan> | hober: the newness isn't a problem in itself :-) |
| 15:21 | <annevk> | smaug____: I'm open to changing that either way |
| 15:21 | <smaug____> | annevk: why ? |
| 15:21 | <smaug____> | annevk: yeah |
| 15:22 | <annevk> | smaug____: well the spec is generic and doesn't list any interfaces |
| 15:22 | <smaug____> | annevk: if the event doesn't have init*, createEvent is useless |
| 15:22 | <annevk> | it will still have initEvent() |
| 15:22 | <annevk> | but sure |
| 15:22 | <smaug____> | well, sure |
| 15:23 | <Ms2ger> | jgraham, duh, should have used XML |
| 15:25 | <odinho> | <img src=ohman.jpg srcset="<srcset><img src='foo.jpg' height='1000' width='1000' resolution='2'></srcset>"> |
| 15:25 | <odinho> | OH MY GOD I FORGOT TO SELFCLOSE /> |
| 15:26 | <Philip`> | Got to use < instead of < to make sure it's polyglottal |
| 15:27 | <odinho> | Philip`: Oh man, totally forgot - good you reminded me. It's going to be awsum. |
| 15:28 | <jgraham> | Oooh, there's a meme for this situation |
| 15:28 | <odinho> | <img src="ohman.jpg" srcset="<srcset><img src='foo.jpg' height='1000' width='1000' resolution='2' /></srcset>" /> |
| 15:28 | <odinho> | There! what a beautify! spec it up |
| 15:30 | <zcorpan> | aha! <source> in srcset=""! |
| 15:30 | <zcorpan> | everybody wins! |
| 15:30 | <odinho> | why didn't I think of that :-/ |
| 15:31 | <annevk> | needs more media query |
| 15:32 | <odinho> | MEDIA QUERY ALL THE THINGS! |
| 15:32 | <odinho> | o/ |
| 15:33 | <samuelfine> | Refresh my memory as to why this isn't a job for media queries? That seems like the most obvious solution to me. I'm probably missing something though. |
| 15:33 | <Philip`> | odinho: Make srcset conditional on a media query, like <img srcset-min-width-800px="<srcset>..." srcset-min-width-400px="..."> |
| 15:34 | <zcorpan> | samuelfine: http://www.xanthir.com/blog/b4Hv0 |
| 15:37 | <samuelfine> | None of the proposals gracefully manage bandwidth concerns, though. |
| 15:38 | <zcorpan> | bandwidth concerns is up to the UA to deal with in the srcset proposal |
| 15:38 | <zcorpan> | there was a suggestion to add byte size information, but no suggestion on what to do with that information |
| 15:38 | <samuelfine> | That's certainly a good reason to avoid using them *now*, but perhaps we should consider improving media queries instead of adding brand new attributes? |
| 15:39 | <samuelfine> | I don't know how this process works, I'm just a lowly developer. It just feels like an overwrought solution to a problem that's already mostly solved. |
| 15:39 | <dglazkov> | good morning, Whatwg! |
| 15:39 | <odinho> | samuelfine: media has conflict with how img is loaded. |
| 15:41 | <samuelfine> | odinho: I'm not sure what you mean. |
| 15:43 | <odinho> | samuelfine: Maybe start with http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035886.html -- and also all the other emails in that thread. There's stuff scattered around in that list. |
| 15:44 | <samuelfine> | odinho: Thanks. I'm still new to this mailing list thing, and trying to grok the site gives me a clot in my brain. |
| 15:45 | <odinho> | samuelfine: It's essential to have a good mail reader. -- I started using Opera M2 again half a year ago, and am very happy I've done that now. It's really nice to have such a good overview over complex discussions. |
| 15:46 | <samuelfine> | odinho: @opera.com recommending Opera Mail? I'm shocked! (Seriously though, I'll check it out. Mail for OS X is the worst.) |
| 15:46 | <odinho> | samuelfine: lol, -- I don't recommend stuff I don't use. I don't use Opera IRC, I use irssi. |
| 15:47 | <ShaneHudson> | I use Sparrow Mail, it is very good |
| 15:48 | <ShaneHudson> | Biggest problem is that I signed up with my email address that also goes to my phone.. not a good idea |
| 15:48 | <odinho> | People in Opera choose their own mail reader, so people use all sorts of different readers. Except Outlook which is banned. |
| 15:49 | <ShaneHudson> | Haha |
| 16:09 | <odinho> | foolip_: Funny email :-) |
| 16:09 | <foolip_> | odinho, which one? |
| 16:09 | <odinho> | foolip_: WHATWG one. <source media> |
| 16:09 | <foolip_> | oh :) |
| 16:10 | <odinho> | I should just stop writing emails in those threads. They just keep growing when I do it :-/ |
| 16:10 | <foolip_> | You can never shrink a thread by replying to it, that is true... |
| 16:10 | <odinho> | So bad, I hate that. |
| 16:10 | <annevk> | I think part of the reason we had <source media> is because the idea was that media queries would be used to determine whether or not the user would want to see subtitles and such by default |
| 16:11 | <annevk> | I think since then we realized that would be way complex and invented something more clever |
| 16:12 | <foolip> | annevk, I didn't search the email archives around that time, do you remember where it was discussed? |
| 16:14 | <odinho> | ShaneHudson: lol, go write that book. |
| 16:15 | <annevk> | foolip: now we have http://lists.w3.org/Archives/Public/public-whatwg-archive/ you can search in both lists at the same time |
| 16:15 | <annevk> | foolip: David Singer brought this up a few times |
| 16:16 | <annevk> | foolip: but given the date of revision 724 this should be easy enough to figure out |
| 16:16 | <ShaneHudson> | odinho: haha I want to write a book somewhen tbh |
| 16:20 | <foolip> | annevk, http://lists.w3.org/Archives/Public/public-whatwg-archive/2007Jun/0126.html is the oldest I can find, but that's after the commit |
| 16:22 | <annevk> | foolip: cannot find the follow up to http://lists.w3.org/Archives/Public/public-whatwg-archive/2007Apr/0059.html |
| 16:23 | <foolip> | I guess we could just ask singer and hixie, if we really wanted to know. |
| 16:24 | <annevk> | did find some youthful optimism http://lists.w3.org/Archives/Public/public-whatwg-archive/2007May/0088.html |
| 16:25 | <foolip> | :) |
| 16:25 | <foolip> | I also found a mail where Lachlan argued something slightly weird about Theora. |
| 16:27 | <annevk> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2007Mar/0663.html mentions media queries |
| 16:33 | <tantek> | annevk - you're like a whatwg list human-search-engine |
| 16:34 | <Ms2ger> | foolip, eww, git :) |
| 16:43 | <ShaneHudson> | adactio: Very good article by the way! (http://adactio.com/journal/5474/) |
| 16:44 | <adactio> | ShaneHudson: thanks. |
| 16:44 | <tantek> | jgraham, FYI, the link you found on that W3C wiki login page has been fixed to link to something more understandable (same as the link on the W3C wiki home page) - for signing up for new accounts: http://www.w3.org/wiki/index.php?title=Special:UserLogin&returnto=Main_Page - thanks to brett in irc://irc.w3.org:6665/sysreq |
| 16:54 | <foolip> | adactio, <picture><source> doesn't mimic the behavior of video at all, the video resource selection algorithm uses the first source that passes all the tests and then never changes |
| 16:55 | <foolip> | but it's not surprising that many people make this mistake, given the complexity of the resource selection algorithm. |
| 16:55 | <adactio> | foolip: A moot point at this juncture, wouldn't you say? |
| 16:56 | <adactio> | foolip: Also, I was talking about how <picture> mimicked the *syntax* of <video>, not necessarily the behaviour. But point taken. |
| 16:57 | <foolip> | adactio, just thought you might want to know :) |
| 16:58 | <foolip> | It's also probably not true that "using media queries on the sources of videos has proven to be very tricky for implementors" but I haven't read all the email so I don't know who claimed that. |
| 17:06 | <jmather> | tantek: wrote up my idea on the CG. Maybe I'm crazy. :D |
| 17:07 | <annevk> | foolip: that's probably in part because for <video> it goes only one way, and when evaluation of the media query changes, the resource does not change |
| 17:08 | <annevk> | foolip: which is quite different from how people expect it to work for <picture> (although nobody has quite articulated how it would work I think) |
| 17:08 | <foolip> | Yes, but it's easy to implement, it just isn't useful. |
| 17:08 | <foolip> | at least it was easy in Opera, or I wouldn't have done it. |
| 17:09 | foolip | counts to 6 lines of code to support it |
| 17:09 | <annevk> | yeah at this point I have a hard time seeing why it was added too |
| 17:09 | <ShaneHudson> | Talking about implementing, is there any ooks or indepth articles for getting started with browser development? Or is it just, clone the source and jump in? |
| 17:10 | <foolip> | ShaneHudson, unfortunately you can't clone Opera, but I'd presume Gecko and WebKit start in that way :) |
| 17:11 | <jmather> | The more I think about it the more I realize MQ's aren't the right way, even if the picture style syntax is/might be/whatever. As has been said, re-evaluation is/would be problematic, plus, the media query selector that's really needed doesn't exist. |
| 17:12 | <ShaneHudson> | foolip: Yes, I wouldn't expect to be able to jump into a paid position! :) |
| 17:20 | <tantek> | ShaneHudson, reporting bugs to various browser's bug databases is one way of getting noticed. |
| 17:26 | <othermaciej> | ShaneHudson: WebKit is pretty approachable |
| 17:26 | <othermaciej> | http://www.webkit.org/building/checkout.html |
| 17:26 | <othermaciej> | http://www.webkit.org/building/build.html |
| 17:29 | <tantek> | well if we're dropping URLs ;) |
| 17:29 | <tantek> | http://www.mozilla.org/contribute |
| 17:29 | <tantek> | https://developer.mozilla.org/en/Introduction |
| 17:29 | <othermaciej> | ShaneHudson: finding and filing bugs is also a great way to get involved, as mentioned by tantek |
| 17:30 | <annevk> | dropping URLs? http://opera.jobs/ |
| 17:38 | <tantek> | ShaneHudson, summary for your convenience: http://wiki.whatwg.org/wiki/Getting_started_with_browser_development |
| 17:39 | tantek | wasn't sure if that was ontopic for the WHATWG FAQ or not so didn't add it - if someone more familiar with the FAQ feels it is ontopic enough, feel free to add it. |
| 18:03 | <MikeSmith> | jgraham: a couple weeks there was something you said I should add the platform.html5.org, but I have since forgotten what it was |
| 18:08 | <annevk> | MikeSmith: should prolly drop From-Origin at this point |
| 18:08 | <MikeSmith> | hai |
| 18:08 | <MikeSmith> | done |
| 18:09 | <othermaciej> | annevk: is From-Origin abandoned? |
| 18:12 | <Ms2ger> | 'parently |
| 18:12 | <othermaciej> | should DNT be added to platform.html5.org maybe? |
| 18:12 | <othermaciej> | or too soon? |
| 18:13 | jwalden | wonders if there's some sort of conference happening that caused #whatwg to be abnormally active yesterday |
| 18:13 | <othermaciej> | jwalden: the ongoing responsive image discussion |
| 18:14 | <Ms2ger> | jwalden, you don't want to read it |
| 18:14 | <Ms2ger> | It's trolling all over |
| 18:15 | <MikeSmith> | othermaciej: I will add DNT. It seems clear it's going to become part of the platform in some form |
| 18:15 | <jwalden> | yeah, I skimmed backlogs super-heavy |
| 18:15 | <jwalden> | Ms2ger: I hear that Ms2ger troll is especially worth not reading |
| 18:15 | <Ms2ger> | I wasn't around, fortunately |
| 18:15 | <jwalden> | haha |
| 18:15 | <jmather> | Ms2ger: i think a lot of it is just more mis-understanding the sides honestly. At first I didn't entirely get where the srcset proposal was coming from |
| 18:16 | <jmather> | i still don't particularly get it or agree with it, but I get you guys have your reasons… I'm now firmly in the camp that everyone is wrong and solving the problem the wrong way, so maybe i'm jus the odd one out. :D |
| 18:17 | <othermaciej> | jmather: do you have a specific better proposal in mind, or better yet, an important use case that is not well addressed by other proposals? |
| 18:17 | <hober> | jmather: i think it's fair to say that there is no, single "the problem" |
| 18:17 | <jmather> | http://www.w3.org/community/respimg/2012/05/16/shouldnt-we-be-defining-content-not-context/ I tried to work in a use-case type scenario but the comment below has a more susinct use case |
| 18:17 | <jmather> | hober: granted. It's a multi-faceted issue, which makes it harder to solve |
| 18:18 | <jmather> | and there is a lot of politics involved with what happened in yesterdays uproar |
| 18:18 | <annevk> | othermaciej: afaik nobody is implementing it |
| 18:18 | <hober> | annevk: DNT? |
| 18:18 | jmather | gets enough politics at work, tries to avoid it elsewhere, hah. |
| 18:18 | <annevk> | hober: from-origin |
| 18:19 | <hober> | annevk: oh, yeah. that makes me sad. i really like from-origin |
| 18:19 | <annevk> | me too :) |
| 18:20 | <Kasey> | jwalden I'm not sure about anybody else, but this is why I just joined the channel: http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/. Really interested to see how this turns out. |
| 18:20 | hober | is still somewhat bitter that we didn't agree to use it for @font-face |
| 18:20 | <Kasey> | the article was just published yesterday |
| 18:21 | jwalden | likes the "I was also there, for some reason." line in that article :-) |
| 18:21 | <othermaciej> | annevk: we'd be down for implementing it in WebKit but it's probably somewhat less useful if not applicable to fonts |
| 18:21 | <annevk> | othermaciej: as currently defined it applies to all resources |
| 18:22 | <jwalden> | jmather: "you must be new here" :-) |
| 18:22 | <othermaciej> | so what's the issue with it and @font-face? |
| 18:22 | <Ms2ger> | The cabal, I suppose |
| 18:22 | <jwalden> | web standards is politics to a decent extent :-) |
| 18:22 | <jmather> | jwalden: Yep. Sure am. That's why I have the crazy ideas. :) |
| 18:22 | <annevk> | @font-face requires CORS now I think |
| 18:22 | <othermaciej> | (mind you, I also don't like the name From-Origin very much but I'm not sure of a better name) |
| 18:23 | <jwalden> | that said, generally we get pretty good ideas out of stuff even with politics in the undertones |
| 18:23 | <othermaciej> | the CSS3 Fonts WD doesn't seem to hard-require CORS, or at lest it leaves the From-Origin possibility open |
| 18:23 | jwalden | has been lurking here four years or so, has contributed directly on the list in the past, mostly has been busy in recent years tho with other stuff |
| 18:24 | <othermaciej> | http://www.w3.org/TR/css3-fonts/#same-origin-restriction |
| 18:24 | <othermaciej> | I guess that is deleted from the ED |
| 18:24 | <Ms2ger> | jwalden, just a decent extent? :) |
| 18:25 | <annevk> | othermaciej: I haven't followed up on that much |
| 18:25 | <jmather> | I just had some ideas one day about who to work towards responsive images and tried to follow along with the CG… now a lot of them are talking about meta variables in the head and that's the complete opposite solution i see as viable… making the content dependent on head variables and such… yikes. :D |
| 18:26 | <jmather> | but that's what made me realize that the approach where browser size determines the image to pull is … problematic. |
| 18:26 | <jwalden> | Ms2ger: eh, it depends; some of the stuff around window.postMessage back in the day (I am showing my age here, and get off my lawn) had a little bit of politics to it, some of it fair-ishly characterizable as coming from Mozilla, and we still got something pretty decent out in the first cut there (that everyone originally implemented, before various improvements to it got spec'd) |
| 18:26 | <jwalden> | probably depends a bit on the issue |
| 18:27 | jwalden | remembers how late that landed in the 3.0 cycle with Mozilla, is glad that argument about changing things so late in a cycle is ancient history now |
| 18:27 | <jwalden> | trains ftw |
| 18:29 | <jwalden> | so having skimmed that article, I think it's safe to say I'm not close enough to web development to know how well either satisfies a reasonable set of the needs people are trying to solve |
| 18:30 | <jwalden> | new elements like <picture> tend to be a hard sell, tho |
| 18:30 | <jwalden> | but shoving everything into a microsyntax in an attribute is unpleasant enough, certainly |
| 18:30 | <jwalden> | meh |
| 18:30 | <annevk> | best go shopping? |
| 18:31 | <jwalden> | assuming you meant "let's", sure :-) |
| 18:31 | <jmather> | at this point i'm for either implementation if we can make it relate to the space for content |
| 18:31 | <othermaciej> | the srcset micro syntax was more readable before the width/height additions |
| 18:32 | <othermaciej> | maybe if you use only width or only resolution it's not so bad |
| 18:32 | <jmather> | though i think i like the longer picture syntax w/ srcset style attributes |
| 18:32 | <tantek> | jwalden, are the use cases you care about covered here? http://www.w3.org/wiki/Images (if so, feel free to add details, if not, add more use cases) |
| 18:32 | <jmather> | the only problem is that polyfill's for srcset implementation will have the double-hit download |
| 18:33 | <annevk> | jwalden: relevant: http://plasmasturm.org/log/495/ |
| 18:33 | <annevk> | jwalden: includes a working(!) pointer to Markup Barbie as a bonus |
| 18:33 | <jwalden> | tantek: the things I can think of that I'd want seem covered by either proposal; as I said, I'm not close enough to web development these days to really experience firsthand the concerns people have, or to super-productively contribute on the point |
| 18:34 | <tantek> | that's interesting because the two proposals appear to focused on solving different problems/use-cases. |
| 18:34 | jwalden | says a prayer for diveintomark.org, bless its soul |
| 18:34 | <jwalden> | tantek: also I didn't read either super-closely |
| 18:34 | <jwalden> | tantek: really I'm probably best ignored on this topic :-) |
| 18:34 | <tantek> | jwalden - hence I'm asking a question from the perspective of needs rather than syntax/proposals |
| 18:35 | <jmather> | tantek: that's where I think the authors and browser guys are butting heads… i think we're trying to solve our own issues and not looking at what the other side is trying to solve |
| 18:35 | <jwalden> | I will claim to be worth listening to when I think there's a chance that's actually the case, and I don't think I would add anything here if I read more deeply :-) |
| 18:35 | <jmather> | using we collectively there :) |
| 18:35 | <othermaciej> | it looks like nearly every thread on whatwg@ is now on responsive images |
| 18:35 | <Ms2ger> | Correct |
| 18:35 | <hober> | yeah, i'm over 100 mails behind :( |
| 18:36 | <jmather> | From what I understand, browser side, the concern is knowing enough about the image to try and make better decisions about what to display and when |
| 18:38 | <jmather> | Am I missing something there or is that a fair summary of srcset's origins? |
| 18:39 | <annevk> | jmather: its origins are clearly explained here http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html |
| 18:40 | <jmather> | Ok, I've raid that. I really wish I could just scream size of the viewport is irrelevant from the mountain tops, but alas… there are no mountain top s here. :D |
| 18:40 | <jmather> | sorry, read, not raid, hah |
| 18:44 | <tantek> | welcome ChrisWilson |
| 18:45 | <ChrisWilson> | :) |
| 18:58 | <Ms2ger> | WebKit guys, has https://bugs.webkit.org/show_bug.cgi?id=32695 been fixed? |
| 18:59 | <ShaneHudson> | python |
| 18:59 | <ShaneHudson> | oops, wrong window! |
| 18:59 | <Ms2ger> | perl! |
| 18:59 | <othermaciej> | Ms2ger: working ok in my build |
| 19:07 | <ChrisWilson> | ms2ger: and in Chrome Stable |
| 19:09 | <Ms2ger> | Eek, it's ChrisWilson |
| 19:09 | <Ms2ger> | And working for Google |
| 19:09 | <Ms2ger> | Still feels weird, I got to say |
| 19:10 | <ChrisWilson> | heh. |
| 19:10 | <ChrisWilson> | Not to me. |
| 19:10 | <ChrisWilson> | Freeing, you might say. |
| 19:19 | jgraham | reads that as "ChrisWilson has 'no underwear' in his Google contract", sells it to an online gossip rag |
| 19:20 | <ChrisWilson> | jgraham: that would not be the worst thing said about me by a very long short. |
| 19:20 | <ChrisWilson> | er, shot. |
| 19:20 | <ChrisWilson> | :) |
| 19:25 | <annevk> | ChrisWilson: go on :p |
| 19:26 | <Ms2ger> | "@Tab - yes I do remember, sorry. I'm being a bloody idiot." |
| 19:26 | <Ms2ger> | If that's your entire email, yes. |
| 19:28 | <ChrisWilson> | annevk: Pretty sure a few things said in this very forum make the cut. :) |
| 19:33 | <dglazkov> | I wonder why the idiot is bloody? |
| 19:33 | <dglazkov> | perhaps there was a terrible accident |
| 19:36 | <jgraham> | dglazkov: I always imagined it more like the black knight from monty python |
| 19:38 | <dglazkov> | oh wow! Monty Python is free on Amazon Prime. Yay, time to watch it all again! |
| 20:32 | <jgraham> | http://pretty-rfc.herokuapp.com/ |
| 20:39 | <othermaciej> | hmm, Media Queries is not a very good spec |
| 20:43 | <annevk> | othermaciej: when I fixed most of its major problems (parsing was undefined and such) it was a bit too late to rewrite the whole thing |
| 20:43 | <othermaciej> | annevk: parsing now seems to be defined, but as far as I can tell, evaluation is undefined |
| 20:43 | <othermaciej> | I can't find a normative statement that would define when a media query property expression is true |
| 20:43 | <annevk> | othermaciej: example? |
| 20:44 | <annevk> | othermaciej: it doesn't use RFC 2119 |
| 20:44 | <othermaciej> | (it also uses "must" in the non-RFC2119 sense a bunch) |
| 20:44 | <othermaciej> | but even overlooking the terminology |
| 20:44 | <othermaciej> | what defines when a media query expression evaluates to true, and when it evaluates to false? |
| 20:45 | <annevk> | I think that would be |
| 20:45 | <annevk> | 'A media query is a logical expression that is either true or false. A media query is true if the media type of the media query matches the media type of the device where the user agent is running (as defined in the "Applies to" line), and all expressions in the media query are true' |
| 20:45 | <othermaciej> | and what defines when an expression evaluates to true? |
| 20:46 | <annevk> | that |
| 20:46 | <annevk> | oh sorry |
| 20:47 | <othermaciej> | that statement is defined in terms of expressions in the media query all being true, and I have a hard time finding an explicit statement of when expressions are true |
| 20:49 | <annevk> | third bullet point in section 4 |
| 20:49 | <annevk> | actually no, that's only for shorthands |
| 20:49 | <othermaciej> | there are some specific defined conditions for when expressions are false |
| 20:49 | <annevk> | yeah so this would have been caught if I had rewritten it |
| 20:50 | <annevk> | anyway, I just patched known problems rather than taking a fresh look at the problem |
| 20:50 | <othermaciej> | it also does not define how to evaluate relative units other than maybe in an example |
| 20:50 | <annevk> | does section 6 not define that? |
| 20:52 | <othermaciej> | ah, mea culpa |
| 20:56 | <othermaciej> | hmm, I have a hard time understanding what the initial value of font-size is (based on CSS 2.1 at least) |
| 20:57 | <Ms2ger> | It's CSS, what'd you expect? :) |
| 20:58 | <annevk> | othermaciej: undefined |
| 20:58 | <annevk> | othermaciej: up the UA |
| 20:58 | <annevk> | othermaciej: typically 16px |
| 20:58 | <othermaciej> | is 'medium' supposed to be a fixed value per UA, or is it supposed to match the value of the current configured font size? |
| 20:58 | <Ms2ger> | I think the latter |
| 21:01 | <othermaciej> | I was trying to figure out if media queries based on 'em' units are actually useful, and my conclusion is that I can't tell |
| 21:18 | <smaug____> | dglazkov: Salty liquorice ice cream is way more effective than beer ;) |
| 21:19 | Ms2ger | keeps that in mind |
| 21:28 | <annevk> | othermaciej: they react to minimum font-size settings but if you change font-size on the root and base your calculations on that it'll go wrong |
| 21:29 | <TabAtkins_> | othermaciej: Heh, I can't believe we didn't actually define when MQs are true. ^_^ |
| 21:36 | <dtharp> | TabAtkins_: yt? |
| 21:36 | <othermaciej> | TabAtkins_: I can't believe it got to PR that way |
| 21:38 | <dglazkov> | smaug____: http://www.icecreamsource.com/Black-Licorice--3-Gallons_p_361.html? |
| 21:38 | <TabAtkins_> | dtharp: pong |
| 21:39 | <dtharp> | TabAtkins_: Hi, I've been implementing MS ietestcenter tests in webkit, and recently found that webkit's 'computeLength()' is not handling vw, vh and vmin. I'm working on a patch for this. The issue I have a question with is that MS seems to have aliased vmin to 'vm' in their test htm. Apparently this alias has been in effect since IE6. The question is, should we alias vmin as 'vm' in webkit as well for compatibility? 'vm' is, of course, not |
| 21:39 | <dtharp> | mentioned in the spec. |
| 21:39 | <TabAtkins_> | 'vm' was the original name used by the spec, but we changed it because it was impossible to tell whether it meant "min" or "max". |
| 21:40 | <TabAtkins_> | I don't think there's a compat problem. |
| 21:40 | <dtharp> | TabAtkins_: Ah, that makes sense. So you think it's fine to add the alias? |
| 21:40 | <smaug____> | dglazkov: :p |
| 21:42 | <dglazkov> | I like licorice. Never had licorice ice cream |
| 21:43 | <ShaneHudson> | I have never even heard of licroice ice cream! |
| 21:43 | <ShaneHudson> | Mint ice cream is good though |
| 21:45 | <tantek> | Mint chocolate chip even. |
| 21:46 | <ShaneHudson> | mmmmm |
| 21:46 | <ShaneHudson> | I have none :( but I am about to grab some gingernut biscuits from the cupboard :) |
| 21:49 | <smaug____> | https://en.wikipedia.org/wiki/File:TotallyBlack.jpg is good |
| 21:52 | <dtharp> | TabAtkins_: sorry for being dense here... when you say "I dont think there's a compat problem", do you mean that if we implment the 'vm' alias for vmin, then at that point we do not have a compatibility issue? or are you saying we *currently* don't have a compat problem, and therefore should NOT implement the 'vm' alias? |
| 21:54 | <annevk> | per spec there is no vm unit |
| 21:54 | <annevk> | I think it would be wrong for a browser to support it |
| 21:55 | <dtharp> | IE10 supports it |
| 21:55 | <ShaneHudson> | Does anyone know when IE10 is being released yet? |
| 21:55 | <annevk> | dtharp: just saying; if it's somehow required then it should be in the spec... |
| 21:56 | <annevk> | dtharp: cannot have every browser have to figure out on their own what to implement |
| 21:57 | <dtharp> | annevk: i agree. I have seen concessions for "common in the wild" stuff before, so was just trying to get clarification. It sounds like the right path here is to get MS to update thier test |
| 22:08 | <TabAtkins_> | dtharp: Sorry for the delay. I think that there is no need to implement a vm unit, so we should leav eit alone. |
| 22:09 | <dtharp> | TabAtkins_: sounds good. I'll work with MS to have them update their test per spec. Thanks! |
| 22:09 | <TabAtkins_> | I didn't even realize we had a computeLength() function, by the way. |
| 22:11 | <dtharp> | TabAtkins_: its actually CSSPrimitiveValue::computeLengthDouble() in CSSPrimitiveValue.cpp |
| 22:11 | <TabAtkins_> | Oh, one of our internal functions. Gotcha. |
| 22:11 | <dtharp> | TabAtkins_: its the target fror a bunch of templates |
| 22:12 | <ShaneHudson> | Are any of you from Google? |
| 22:14 | <TabAtkins_> | ShaneHudson: I am. I don't think dtharp is. |
| 22:15 | <TabAtkins_> | (At least, his name doesn't have any matches when I search on our employee database.) |
| 22:15 | <ShaneHudson> | Excellent, is it alright to pm you? |
| 22:16 | <TabAtkins_> | ShaneHudson: Go for it. |
| 22:18 | <TabAtkins_> | annevk: I doubt there's a compat need to support vm. IE was the only browser to support it, and use of the viewport-relative values wasn't common afaik. |
| 22:21 | <annevk> | yeah |
| 22:21 | <annevk> | should have a negative test for vm really |
| 22:36 | <zewt> | annevk: https://www.khronos.org/webgl/public-mailing-list/archives/1205/msg00135.html :| |
| 22:40 | <TabAtkins_> | zewt: Holy mother of god no. |
| 22:40 | <zewt> | was: re: :| |
| 22:40 | <TabAtkins_> | Why? Why won't people learn? We made mistakes! |
| 22:40 | <zewt> | things not to take inspiration from: |
| 22:40 | <zewt> | java |
| 22:40 | <zewt> | xml |
| 22:40 | <zewt> | note: list not exhaustive. |
| 22:41 | <zewt> | (several times i've seen webgl people go "we can't do it that way. java did it and it sucked!" because clearly if java can't do something well, it can't be done, right?) |
| 22:41 | Philip` | recently found that OpenGL and OpenGL ES have incompatible extensions with exactly the same name, which is fun, especially since some desktop GL drivers implement both GL and GLES extensions |
| 22:41 | <TabAtkins_> | I mean, for chrissakes, the XML people themselves finally admit that namespaces were a mistake. |
| 22:42 | <zewt> | call me cynical, but it smells a lot more like "i want my name in the webgl spec, implement this random thing i thought of for a bunch of contrived reasons" |
| 22:43 | <zewt> | maybe i've just been doing the open source thing too long, heh |
| 22:43 | <gsnedders> | WebGL is a clusterfuck. Is this not obvious? |
| 22:43 | <gsnedders> | (News at 10, move on.) |
| 22:43 | <zewt> | it's not XML-level clusterfuck |
| 22:43 | <zewt> | that's more like clusterbomb-fuck |
| 22:43 | <zewt> | (is that a thing?) |
| 22:44 | <gsnedders> | clusterbomb-clusterfuck. |
| 22:45 | <gavinc> | at least XML got unicode and utf-8 by default right? ... than it added letting you set your own encoding which sort of lets it down a bit... |
| 22:46 | <zewt> | we could go in circles for hours about what xml got wrong :) |
| 22:47 | <gsnedders> | gavinc: Look at the EDBIC stuff in it, like dfn of space characters in 1.1 (there again, nobody gives a shit about 1.1) |
| 22:48 | <gavinc> | Speaking of which... if anyone here would like to point out everything we got wrong http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html# BEFORE going to last call. Other than it's RDF and is killing the web. |
| 22:48 | <gavinc> | Last call next week and all that |
| 22:49 | <zewt> | does "i have no clue what this is for after reading the introduction" count? |
| 22:49 | <gavinc> | Yes. |
| 22:50 | <zewt> | (i have no idea what RDF is; a paragraph summarizing this in isolation, assuming no knowledge of whatever that is, might be useful--if that's possible) |
| 22:50 | <gsnedders> | gavinc: Have a N-Triple example in the Intro too. |
| 22:50 | <gsnedders> | (Ideally semantically identical to the Turtle one) |
| 22:50 | <zewt> | ("turtle" makes me think it has something to do with Logo. heh) |
| 22:51 | <gavinc> | gsnedders: good point |
| 22:51 | <gsnedders> | gavinc: Don't recommend CDATA sections for embedding in XHTML (as then people will fail to handle the case where ]]> appears in a string) |
| 22:52 | <gavinc> | gsnedders: if you can show any other way of embedding in XHTML I'm all for it |
| 22:52 | <gsnedders> | "THe HTML lang attribute" has an obvious typo |
| 22:52 | <gsnedders> | gavinc: Escape everything, as painful as it is. |
| 22:52 | <gsnedders> | gavinc: But otherwise people are unlikely to handle ]]> correctly. |
| 22:52 | <gavinc> | gsnedders: mmm... does that work in polyglut documents? |
| 22:52 | <TabAtkins_> | I agree with gsnedders, since ]]> is a vital part of ascii fishes. |
| 22:52 | <gsnedders> | At least note "]]>" cannot be represented within a CDATA section. |
| 22:53 | <gsnedders> | gavinc: CDATA doesn't, escaping everything does. |
| 22:53 | <gavinc> | Perfect. |
| 22:53 | <gavinc> | also, don't use XHTML... but hey ;) |
| 22:53 | <gsnedders> | gavinc: 12.3 uses what BNF form? |
| 22:54 | <gavinc> | ah, yes W3C EBNF... |
| 22:54 | <gsnedders> | gavinc: That seems to be noted in 5.4 but not 12.3 |
| 22:54 | gavinc | nods |
| 22:54 | <gsnedders> | gavinc: Why does it cite XML 1.0 3rd Edition and not 4th? |
| 22:54 | <gsnedders> | (Or, perhaps contravercially, 5th?) |
| 22:54 | <gavinc> | should be 5th... |
| 22:55 | <gavinc> | the link is to 5th... |
| 22:55 | <gsnedders> | http://www.w3.org/TR/REC-xml/#sec-notation is the URL given, and it explicitly states an edition, which is obviously nonsense |
| 22:55 | <gavinc> | Yes. |
| 22:56 | <gavinc> | remove words Thrid Edition ;) |
| 22:56 | <gsnedders> | gavinc: Can you aggregate everything I've said and pass it along? |
| 22:56 | <gavinc> | faster, I can edit it ;) |
| 22:58 | gsnedders | moves to #swig |
| 23:00 | <espadrine> | /join #swig |
