Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 21.05.2012 07:49 schrieb Mike Gossmann:
img src=/img/people.jpg sizes=100x200 300x250 900x300
pattern=/tools/resizer.php?img=people.jpgamp;width={w}amp;height={h} alt=A picture of some
people.
I am somehow surprised that there are no reactions to this proposal. To
me as a humble author it looks like it would address the main issue of
both picture and @srcset, as it leaves the MQ to CSS, and thus
separates design from content.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both picture and @srcset, as it leaves the MQ to CSS, and thus separates design from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 22 May 2012 10:43, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both picture and @srcset, as it leaves the MQ to CSS, and thus separates design from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. It doesn't address the art-direction use case either - http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ Andy
Re: [whatwg] responsive images
I've been trying to follow this thread for a week now, but I'm a bit lost, so
apologies if this is the wrong place.
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on sites. As a programmer, it has very much got what we
would call a bad code smell.
img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x,
face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h
Not to mention, what happens when a 3x device is released?
Do I have to change all my code again?
I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96?
and isn't 600-200@2 just the same as 1200-400@1?
Wouldn't it be more future proof, instead of making the author supply a never
ending string of image names, implement variable logic (I think first suggested
by Matthew Wilcox). However, instead of the suggestion of putting as a head
meta tag, perhaps the logic could be confined to the img tag (or a
picture tag to allow slightly smoother transition).
Perhaps something like this:-
picture
src=some.img?{width}-{height}@{dpi}
img src=some-fallback.img
/picture
You could then define a list of parameters that the browser supports as
replacements. Eg. viewport-width/height, dpi, density. This could also be
carried over to other tags.
It also allows the author to decide what to implement as a fallback / low
bandwidth option. Personally, I could make: img
src=some_{width}-{height}@{dpi}.png return a perfectly valid image on my
webserver if an older browser failed to substitute the params.
Like I said at the start, I'm a bit lost as a newcomer to the debate, but there
seems to be suggestions floating around for better / more future proof / more
elegant solutions than the srcset above, but they don't seem to be getting any
traction.
Paul
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 22, 2012, at 5:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both picture and @srcset, as it leaves the MQ to CSS, and thus separates design from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. We’re apt to see the element used in one of two ways: * Serving a size-appropriate image source in a flexible layout, wherein the size of the images will be controlled by CSS—typically, `max-width: 100%`. Using a pixel density MQ will serve a larger image within this constraint. Inherent size is not a concern with this case—which is fortunate, as this will likely require sources with varying dimensions, per the “art direction” case. * Serving a static-dimension asset at varying resolutions, a la Apple.com. To always rely on the intrinsic size of another source is to negate the art direction use case — however, we could simply add optional `width` and `height` attributes to `picture`, constraining the higher res image to a specified set of dimensions. This leaves control in the authors’ hands in a simple, predictable way without negating either use case. I can’t speak to this personally, but Kornel has mentioned that using said attributes instead of relying on a calculated inherent width will avoid reflows. It should likely be an option in either case. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] responsive images
On 22 maj 2012, at 05:53, Paul Court p...@pmcnetworks.co.uk wrote:
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on sites. As a programmer, it has very much got what
we would call a bad code smell.
img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h
1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h
Not to mention, what happens when a 3x device is released?
2x image will be used, upscaled.
I think that 3x device is very very unlikely to ever happen, since 2x screens
are may be dense enough to have pixels smaller than human eye can see.
1x and 2x are. Is it 2x 72 or 2x 96?
and isn't 600-200@2 just the same as 1200-400@1?
'x' is not a media query, but property of the image.
600@2 is a higher quality version of 300@1.
Perhaps something like this:-
picture
src=some.img?{width}-{height}@{dpi}
img src=some-fallback.img
/picture
You could then define a list of parameters that the browser supports as
replacements. Eg. viewport-width/height, dpi, density. This could also be
carried over to other tags.
If width/height is a virwport size then it will generate lots of unique URLs
(requires server to generate many images and proxies to cache them separately),
and may generate lots of requests when window is resized.
It doesn't work with static file servers, and may be costly/problematic for
CDNs.
Another risk is that authors will create files only for size/DPI of iPhone and
iPad and never supply images for 3000 other resolutions of various Android
devices.
--
regards, Kornel
Re: [whatwg] responsive images
(I wish people would stop starting new threads about the same topic.) On Tue, May 22, 2012 at 5:53 AM, Paul Court p...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Actually, it's pretty clean; you've just made it ugly by sticking it all on one line. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h It's no uglier than CSS syntaxes like background. Not to mention, what happens when a 3x device is released? Do I have to change all my code again? It'll use the best match, which is most likely the 2x version. I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96? It means two hardware pixels per CSS pixel, which is what you get on iPhones, and also what you'll get if the user has zoomed in by 2x (eg. ctrl-+ in most desktop browsers). It's not related to DPI. and isn't 600-200@2 just the same as 1200-400@1? First, 600w 200h does not mean a 600x200 image; it means an image targetting 600x200 screens. Some syntax changes have been discussed to make this more clear. Second, the 2x means the the width and height of the image are 1/2 the intrinsic dimensions of the image. For example, if you have a logo which is 400x150 on regular 1x displays, then a 2x option would be an 800x300 image which is displayed as if you wrote img src=url width=400 height=150. That means it takes the same amount of space in CSS pixels--400x150--but you get the higher detail from the 2x density screen (like iPhones), without changing the layout of the page. -- Glenn Maynard
Re: [whatwg] responsive images
On 2012-05-22 17:02, Glenn Maynard wrote: (I wish people would stop starting new threads about the same topic.) On Tue, May 22, 2012 at 5:53 AM, Paul Courtp...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Actually, it's pretty clean; you've just made it ugly by sticking it all on one line. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h It's no uglier than CSS syntaxes like background. It may not be uglier but it's much more fragile as the examples and the prose in the spec give the impression that you can use the , to tokenize, which would be incorrect. ... Best regards, Julian
Re: [whatwg] runat (or server) attribute
Hi, When we started developing Wakanda, a member of the team asked if it would be revelent to support the runat attribute in the script tag It is supported by ASP, and Aptana Jaxer choose to support it as well (Note: even PHP support it) We rejected it Such feature is a bad incitation for the developer to mix its server-side code in what is meant to be the view We never embed any JavaScript code in the HTML, we always put it in separate JS files If one wants to generate HTML from server-side JavaScript, we recommend to use a template engine like mustache.js or pure (many others exist) On 13 mai 2012, at 02:47, Brett Zamir wrote: Hi, With Server-Side JavaScript taking off, could we reserve runat (or maybe an even simpler and more concise server boolean attribute) for a standard and (via CommonJS) potentially portable way for server-side files to be created (and discourage use of HTML-unfriendly and syntax-highlighter-unaware processing instructions)? I know in the past Ian has showed a lack of interest in tending to HTML in other contexts (e.g., in rejecting a common include syntax), but could we at least lay this simple foundation for encouraging server-side portability (in a way that works well with existing syntax highlighters)? Thanks, Brett Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
[whatwg] Make files attribute of the input element writable
Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? Nico 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 22.05.2012 12:46 schrieb Andy Davies:
On 22 May 2012 10:43, Anne van Kesterenann...@annevk.nl wrote:
On Tue, May 22, 2012 at 10:21 AM, Markus Ernstderer...@gmx.ch wrote:
I am somehow surprised that there are no reactions to this proposal. To me
as a humble author it looks like it would address the main issue of both
picture and @srcset, as it leaves the MQ to CSS, and thus separates design
from content.
1. It does not address the pixel density use case. 2. A pattern-based
approach was actually mentioned in Ian Hickson's email when he
announced the srcset attribute.
It doesn't address the art-direction use case either -
http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/
You can do art direction by setting the width in the style sheet:
@media all and (max-width: 500px) {
.contentimg {
width: 100px;
}
}
@media all and (min-width: 501px) and (max-width: 800px) {
.contentimg {
width: 300px;
}
}
@media all and (min-width: 801px) {
.contentimg {
width: 500px;
}
}
img class=contentimg
src=img/obama-500x333.jpg
sizes=100x67 200x134 300x200 500x333
pattern=img/obama-{w}x{h}.jpg
alt=President Obama speaking at a Chrysler plant
You supply a cropped image with 100x67 and 200x134 versions, and the
full image with the bigger versions, which serves the art direction use
case. Retina displays that match the first MQ will likely use the
200x134 version rather than the 100x67 one, which serves the pixel
density use case.
I admit that it is not entirely intuitive, and does not give the author
full control. There may be conflicts between a cropped 200px wide image
intended to use in 2x displays, and a full 200px wide image for bigger
but 1x displays. Or a future 3x display may use the 300x200 version,
where the visual situation would require the cropped image.
I am far away from insisting in this solution; I am aware of the fact
that there have been long discussions by people who have far more
understanding on the topic than myself.
It looks to me like the pixel density use case is better addressed by
leaving the choice on the appropriate resource to the UA, and providing
it information on the resources rather than a MQ. While the art
direction use case is better addressed with a MQ undoubtedly.
Re: [whatwg] srcset javascript implementation (Respondu)
Hey brenton, No I've not pulled respondu.davidmarkclements.com, but I noticed it was down a few times, looked into and found my domain provider had over written two of the nameserver records (lesson: cheap doesn't always pay), this has been corrected but of course propagation takes a while. If you try again a few times eventually it'll reach a valid name server. In under 36hours max this should be a non issue - apologies to anyone who had problems with this. --Original Message-- From: brenton strine To: David Clements Subject: Re: [whatwg] srcset javascript implementation (Respondu) Sent: 22 May 2012 20:49 On Sun, May 20, 2012 at 7:21 PM, David Clements huperekch...@googlemail.com wrote: You can also see working examples at http://respondu.davidmarkclements.com/ Did you pull this down recently? It doesn't seem to be working for me. Sent from my BlackBerry® smartphone on O2
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 23:19 schrieb Kornel Lesiński: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Maybe the use cases should be solved independent from each other: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture This leaves the whole design choice to the author, and gives the UA the full choice on what resource to use. Instead of coping with various kinds of MQs, the author can just specify the sources available, and the UA will make the choice based on the situation. The 0.5px version in my example would be intended for use with very low bandwidth, or for a UA that may progressively load sources as we know it from old progressive GIFs.
Re: [whatwg] responsive images
On Tue, May 22, 2012 at 3:53 AM, Paul Court p...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Not to mention, what happens when a 3x device is released? Do I have to change all my code again? In the short term, the 3x browser can choose to either download the 1x or 2x, whichever it feels would be better. If you want to address it directly, yes, you'd need to change your @srcsets to have a new 3x url as well. Unfortunately you can't get away from that unless you abstract the functionality into CSS or similar, which forces the images to start downloading later. I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96? Standard resolution for the web is 96dpi. and isn't 600-200@2 just the same as 1200-400@1? Yes and no. They have the same number of pixels, yes, and may even be the same image. However, the former has a better intrinsic size, which is used when you don't specify an explicit @width or @height. As well, the main reason for specifying a 2x image is that the browser *knows* that it's 2x, and so is probably about 4 times the size of 1x image in similar circumstances, plus is specifically designed for retina displays and the like. All of this is very useful information to allow the browser to decide which one to download. Wouldn't it be more future proof, instead of making the author supply a never ending string of image names, implement variable logic (I think first suggested by Matthew Wilcox). However, instead of the suggestion of putting as a head meta tag, perhaps the logic could be confined to the img tag (or a picture tag to allow slightly smoother transition). [snip details] That's a possibility, yes. However, it's substantially more complex, as it invokes an entirely new mechanism of url rewriting in addition to the existing complexity. It also means that every responsive image on your page needs to serve images for the full cross-product of things that you support - you can't, say, only do multiple resolutions for your large images. On Tue, May 22, 2012 at 7:26 AM, Kornel Lesiński kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. ~TJ
Re: [whatwg] Features for responsive Web design
On May 21, 2012, at 9:37 PM, Kornel Lesiński kor...@geekhood.net wrote: There’s no prior precedent this sort of thing—there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] Features for responsive Web design
Sorry, I forgot to clarify this ― I had in mind adding width/height on each source element, not on picture. -- regards, Kornel On 22 maj 2012, at 16:01, Maciej Stachowiak m...@apple.com wrote: On May 21, 2012, at 9:37 PM, Kornel Lesi��ski kor...@geekhood.net wrote: There’s no prior precedent this sort of thing―there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] responsive images
On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. -- regards, Kornel
Re: [whatwg] responsive images
On 5/22/2012 3:08 PM, Kornel Lesi��ski wrote: On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. 3x may happen with browser zoom on desktop and on mobile -- Chrome goes to 500%. -Charles
Re: [whatwg] responsive images
On Tue, May 22, 2012 at 3:08 PM, Kornel Lesiński kor...@geekhood.net wrote: On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesiński kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. My friends on the rendering side assure me that AA is still an immensely annoying part of the platform, and *many* things in the code will end up *much* simpler when we can stop dealing with it. ~TJ
Re: [whatwg] Make files attribute of the input element writable
Proposed WebKit patch https://bugs.webkit.org/show_bug.cgi?id=87154. We'd really like to hear if Hixie and/or other browser vendors have reservations on making this change, otherwise, we'll commit this soon. On Tue, May 22, 2012 at 10:41 AM, Nico Weber tha...@chromium.org wrote: Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? Nico 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
Re: [whatwg] Make files attribute of the input element writable
Proposed Firefox patch https://bugzilla.mozilla.org/show_bug.cgi?id=757664 On Tue, May 22, 2012 at 4:10 PM, Ojan Vafai o...@chromium.org wrote: Proposed WebKit patch https://bugs.webkit.org/show_bug.cgi?id=87154. We'd really like to hear if Hixie and/or other browser vendors have reservations on making this change, otherwise, we'll commit this soon. On Tue, May 22, 2012 at 10:41 AM, Nico Weber tha...@chromium.org wrote: Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? Nico 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
The patern thing is tangential. SRCSET using image dimensions instead of screen dimensions would work just as well, so would picture if it was set up to allow saying what the dimensions of each image are. I would argue that this does address the pixel density issue though. It does it in the same way it handles em, rem, or percentage based designs: by ignoring all that stuff and just picking the image that best fits the available hardware pixels. It's more future proof too, since you 200w 200h 2x image could also stand in as your 100w 100h 4x image, if/when something like that comes out, without any updates needed. Art direction is solved in a simialir way: don't provide any images that look bad, and don't size the img element to a size you don't have a picture for. Using the image dimensions instead of the screen dimensions also solves the desktop first vs mobile first dilemma. Syndication becomes easier (or are your breakpoints the same as readability's?), updating the design becomes easier (no editing every image in every post because a breakpoint changed) and really simplifies use cases like the following: You're making a grid of thumbnails. At it's largest size, it's three images across. It stays this way until the images are 2/3 their size, at which point it changes to 2 columns at the original size. When the images hit half their original size, it switches to one column, full size. So one image is created at the three most likely sizes (1/1, 1/2, 1/3) and then srcset is used to make sure the -- Mike Gossmann Mathew Marquis m...@matmarquis.com wrote: On May 22, 2012, at 5:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both picture and @srcset, as it leaves the MQ to CSS, and thus separates design from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. We’re apt to see the element used in one of two ways: * Serving a size-appropriate image source in a flexible layout, wherein the size of the images will be controlled by CSS—typically, `max-width: 100%`. Using a pixel density MQ will serve a larger image within this constraint. Inherent size is not a concern with this case—which is fortunate, as this will likely require sources with varying dimensions, per the “art direction” case. * Serving a static-dimension asset at varying resolutions, a la Apple.com. To always rely on the intrinsic size of another source is to negate the art direction use case — however, we could simply add optional `width` and `height` attributes to `picture`, constraining the higher res image to a specified set of dimensions. This leaves control in the authors’ hands in a simple, predictable way without negating either use case. I can’t speak to this personally, but Kornel has mentioned that using said attributes instead of relying on a calculated inherent width will avoid reflows. It should likely be an option in either case. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Make files attribute of the input element writable
On Tue, May 22, 2012 at 10:41 AM, Nico Weber tha...@chromium.org wrote: Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? I don't think simply marking the attribute as writable is the correct solution here. At the very least we should make it possible to assign a sequenceFile to the attribute such that you can do: myInput.files = [file1]; But even a sequenceBlob should be allowed IMO. One concern I have though is that this is pretty problematic UI-wise. Simply displaying the .name (if it's a file) property in the UI seems like a good way to scare people into thinking that they have attached something that they didn't. / Jonas
Re: [whatwg] srcset javascript implementation (Respondu) [updated]
Hey all, Just wanted to thank Julian and Glenn for their help in pointing me in the right direction for the srcset implementation in the Respondu framework. Respondu srcset now works with url's containing commas, as it more closely follows the parsing algorithm, If anyone takes a look at the improved code (https://github.com/davidmarkclements/Respondu/blob/master/R.js#L230-L295) and spots any other oversights I'd be so grateful if you let me know about it (either on the list, or by filing a github issue). If anyone has any other questions about the Respondu framework, I'd look forward to answering them! All the best, Dave
Re: [whatwg] Make files attribute of the input element writable
It seems like making FileList mutable would serve the same use case and would also be more flexible (as you could upload a set of files collected from possibly multiple sources). And it seems like adding is a more likely desired behavior than replacing when dragging files onto a multi-file input. I have not yet fully thought through the security implications of either case. Do you have any security analysis you could share? For instance, is there an exhaustive list of ways a Web page could obtain a FileList, and are we confident that all are safe for this use? Also: wouldn't anyone doing fancy drag-n-drop file upload be likely to use XHR for upload rather than a form submission? Cheers, Maciej On May 22, 2012, at 10:41 AM, Nico Weber tha...@chromium.org wrote: Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? Nico 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
