Re: [whatwg] The pic element
Am 01.06.2012 um 20:24 schrieb Kornel Lesiński: On 1 cze 2012, at 00:58, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: • Improved alternative text — allows structured fallback, avoids duplication. This is where I do not agree. If you use MQ style with source you have a messy markup when writing alternative text inside the pic-element. Since source is not read nor displayed, it doesn't matter. You can simply treat entire content as fallback. Sure but why? It is much more clearly to use the alt-attribute than using text between container and child elements IMO. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. Structure is there to aid screen readers. See http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0216.html pic src=portrait.jpg (orientation:portrait), landscape.jpgalt text/pic Selects image based on orientation of the device. Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. It is noisier of course but also clearer. I think this is a matter of personal preference. Embeds image at 192dpi (default scaling is 2x, possible to override with CSS). Same as `pic src=image.jpg 2xalt text/pic` or `img src=100x100px width=50 height=50 alt=alt text`. Why is default scaling 2x? A default image should always be @1x, right? We already have element for 1x images – img In the future 1x displays will be low-end minority and 2x will be the norm. It'll be annoying for designers that the default looks terribly and every page always needs the bad default overridden. I'm trying to avoid need for yet another opt-out from the past like doctype and meta charset. It'd be great if in 10-20 years all you had to do is type pic src instead of img src to get first-class support for hires images. To address Tab's concern the default is connected to image-resolution in CSS, so you can change it if you need to: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html Yes but won't we at least dimiss img from our new code? I thought img is only the fallback… And then we should always serve the minimum resolution first. Regardless which resolution this minimal file has, it should be the @1x IMO. Or am I missing something? (I'm not sure if `source` should allow microsyntax in `src` `source src=b 3x` instead of `resolution=3x`) I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: source src=b media=3x Resolution descriptor is not a media query. I'd like to make that clear — it's not merely an abbreviation of min-device-pixel-ratio, it's a property of the image — more similar to width/height attributes. Fair enough :-) After thinking a bit about it it sounds better this way. Cheers, Anselm
Re: [whatwg] The pic element
Am 01.06.2012 um 21:01 schrieb Julian Reschke: On 2012-06-01 20:24, Kornel Lesiński wrote: ... If there are commas or backslashes in the URL they must be escaped with `\`. This is another problem why I would separate the diff. srces. Escaping an URL is not something that should be necessary in HTML I think. I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. ... An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. Best regards, Julian I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. -Anselm
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. Another character could work in theory, but I wonder whether it would work in practice. For example meta name=viewport was documented to support only comma, but thanks to silent error recovery authors ended up using and relying on semicolon: http://lists.w3.org/Archives/Public/www-style/2011Oct/0652.html I wonder whether reverse of it could happen with list of sources, e.g. unexpected comma parsed as invalid media query could end up delimiting sources in some implementations, and then we'll end up with worst of both worlds (both ambiguous comma and other unintuitive delimiter needed for web-compat). -- regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 00:56:55 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. I’m still digesting the overall proposal, but regarding the media-* and src-* attributes, my main concern would be limiting ourselves by prescribing a set number of sizes (e.g. small, medium, and large) when in reality there may be more nuance in art direction than that. might accommodate. That is only partially true because this is just a proposal by me which can easily be changed to another not limiting syntax… But nevertheless you might not have more than 9 different file-sizes, right? This is what is covered by mine (xxxs, xxs, xs, s, m, l, xl, xxl, xxxl). I initially presumed that any name could be used, similarly to data-*, e.g. src-foobar= media-foobar=. However, that doesn't imply any ordering (attributes don't have order by definition), and that complicates source selection algorithm. In that case I think the syntax with separated attributes is less clear than a microsyntax in a single attribute — list in a single attribute has obvious ordering and doesn't rely on an ordered set of predefined names. -- regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 01:02:55 -0500, Anselm Hannemann Web Development
i...@anselm-hannemann.com wrote:
• Improved alternative text — allows structured fallback, avoids
duplication.
This is where I do not agree. If you use MQ style with source you
have a messy markup when writing alternative text inside the
pic-element.
Since source is not read nor displayed, it doesn't matter. You can
simply treat entire content as fallback.
Sure but why? It is much more clearly to use the alt-attribute than
using text between container and child elements IMO.
object, iframe and canvas use content as a fallback. XHTML2 was
supposed to use this fallback model for all elements (global src). It
seems that img alt was just a mistake made in early development of HTML.
Since it's impossible to introduce void element at this point (XML and DTD
boats have sailed …or sunk) we'll have to have /pic anyway. At least we
can make the best of it and use it for rich fallback that wasn't possible
with img before, and which is harder to ignore than an attribute,
because the parser will require /pic.
I'm trying to avoid need for yet another opt-out from the past like
doctype and meta charset.
It'd be great if in 10-20 years all you had to do is type pic src
instead of img src to get first-class support for hires images.
To address Tab's concern the default is connected to image-resolution
in CSS, so you can change it if you need to:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html
Yes but won't we at least dimiss img from our new code? I thought img is
only the fallback…
And then we should always serve the minimum resolution first.
Regardless which resolution this minimal file has, it should be the @1x
IMO.
Or am I missing something?
Yes, img is the fallback until all UAs start supporting the new element.
I'm not sure what do you mean by we should always serve the minimum
resolution first. If alternatives are offered to the UA, IMHO it should
be up to UA whether it downloads low-res first or only high-res image.
I'm afraid that when high-dpi displays become the norm the minimal useful
HTML template will grow to be something like:
!DOCTYPE html
meta charset=UTF-8
stylehtml {image-resolution:2dppx}/style
and I'm trying to find a way to avoid having all authors add yet another
boilerplate opt-in.
I don't know what to do with default-lowres background-image, so maybe
this is an unavoidable problem :(
--
regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 09:58:52 +0200, Kornel Lesiński kor...@geekhood.net wrote: Since it's impossible to introduce void element at this point It's not impossible, but we generally try to only do it when there's a container (like video) so it gets popped off the stack soon enough to not break the whole page in old browsers. However, when we *want* fallback, we *should* use a non-void element, because using the content as fallback is better than using an attribute as fallback: * It actually gets rendered in old browsers instead of getting ignored. * It supports rich markup (which enables e.g. tagging multiple languages, bidi, ruby, etc). canvas was originally implemented as a void element in Safari, but was specced as as non-void element for the above reasons. -- Simon Pieters Opera Software
Re: [whatwg] The pic element
On 2012-06-04 09:32, Kornel Lesiński wrote: On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. Another character could work in theory, but I wonder whether it would work in practice. For example meta name=viewport was documented to support only comma, but thanks to silent error recovery authors ended up using and relying on semicolon: http://lists.w3.org/Archives/Public/www-style/2011Oct/0652.html I wonder whether reverse of it could happen with list of sources, e.g. unexpected comma parsed as invalid media query could end up delimiting sources in some implementations, and then we'll end up with worst of both worlds (both ambiguous comma and other unintuitive delimiter needed for web-compat). 1) Use a format where the delimiter is always the same, (2) where escaping never is needed, and (3) specify the parser to ignore all malformed attribute values. Best regards, Julian
Re: [whatwg] The pic element
Am 01.06.2012 um 21:19 schrieb Aaron Gustafson: On Fri, Jun 1, 2012 at 3:05 PM, whatwg-requ...@lists.whatwg.org wrote: Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. I’m still digesting the overall proposal, but regarding the media-* and src-* attributes, my main concern would be limiting ourselves by prescribing a set number of sizes (e.g. small, medium, and large) when in reality there may be more nuance in art direction than that. might accommodate. Cheers, Aaron That is only partially true because this is just a proposal by me which can easily be changed to another not limiting syntax… But nevertheless you might not have more than 9 different file-sizes, right? This is what is covered by mine (xxxs, xxs, xs, s, m, l, xl, xxl, xxxl). -Anselm
Re: [whatwg] The pic element
On 1 cze 2012, at 00:58, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: • Improved alternative text — allows structured fallback, avoids duplication. This is where I do not agree. If you use MQ style with source you have a messy markup when writing alternative text inside the pic-element. Since source is not read nor displayed, it doesn't matter. You can simply treat entire content as fallback. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. Structure is there to aid screen readers. See http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0216.html pic src=portrait.jpg (orientation:portrait), landscape.jpgalt text/pic Selects image based on orientation of the device. Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. Embeds image at 192dpi (default scaling is 2x, possible to override with CSS). Same as `pic src=image.jpg 2xalt text/pic` or `img src=100x100px width=50 height=50 alt=alt text`. Why is default scaling 2x? A default image should always be @1x, right? We already have element for 1x images – img In the future 1x displays will be low-end minority and 2x will be the norm. It'll be annoying for designers that the default looks terribly and every page always needs the bad default overridden. I'm trying to avoid need for yet another opt-out from the past like doctype and meta charset. It'd be great if in 10-20 years all you had to do is type pic src instead of img src to get first-class support for hires images. To address Tab's concern the default is connected to image-resolution in CSS, so you can change it if you need to: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html (I'm not sure if `source` should allow microsyntax in `src` `source src=b 3x` instead of `resolution=3x`) I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: source src=b media=3x Resolution descriptor is not a media query. I'd like to make that clear — it's not merely an abbreviation of min-device-pixel-ratio, it's a property of the image — more similar to width/height attributes. An `img` element can be used in place of any `source`. `width`/`height` defines size to display selected image at, but does not take part in selection of alternatives. If you could take the alt-text into pic and source I fully'll agree. You should be able to specify an alt-tag for every source if needed (in most use cases it isn't but in some it is if you have another crop with same meaning but different contents) Alt is not supposed to be description of the image. It's supposed to be alternative content to be used instead. e.g. not red triangle with exclamation mark but warning! So different alternative for each source would imply that purpose/meaning of the content changes with viewport size, and that'd be weird — content read to the user would change based on size of the window that a screen reader user may not even see? The common syntax for use with JS polyfills is expected to be: pic src=…noscriptimg src=… alt=…/noscript/pic ##In formal terms The `pic` element requires closing tag. The content is interpreted as a fallback for UAs that don't support `pic` or don't display the image (fallback includes text in img alt inside pic). I wouldn't necessary require a closing tag if you use the short syntax because the alt-text should be in attribute. Void element is not an option due to backwards compatibility. If there are commas or backslashes in the URL they must be escaped with `\`. This is another problem why I would separate the diff. srces. Escaping an URL is not something that should be necessary in HTML I think. I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. * `media` — same as `media` part in `pic src` * `resolution` — same as `resolution` part in `pic src` * `src` — single URL without escaping or microsyntax * `width` and `height` — analogous to `img width/height` for each alternative image * alt * title are missing IMO. title is global, so available for pic too. Might be worthwhile to specify how title on source behaves. As I've mentioned earlier I think it's not
Re: [whatwg] The pic element
On 2012-06-01 20:24, Kornel Lesiński wrote: ... If there are commas or backslashes in the URL they must be escaped with `\`. This is another problem why I would separate the diff. srces. Escaping an URL is not something that should be necessary in HTML I think. I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. ... An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. Best regards, Julian
Re: [whatwg] The pic element
On Fri, Jun 1, 2012 at 3:05 PM, whatwg-requ...@lists.whatwg.org wrote: Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. I’m still digesting the overall proposal, but regarding the media-* and src-* attributes, my main concern would be limiting ourselves by prescribing a set number of sizes (e.g. small, medium, and large) when in reality there may be more nuance in art direction than that. might accommodate. Cheers, Aaron Aaron Gustafson @aaronGustafson
[whatwg] The pic element
Here's a bit of a kitchen sink solution with ideas that floated around.
• I've used media queries for the art-directed use-cases, because:
viewport size descriptors of srcset are confusing, limited (e.g. you can't
have separate image only for print), and there must be an option to always
predictably select image in conjunction with same `@media` in CSS (to
adapt size of other page elements to the picture).
• Browser-controlled resolution adaptation is good, so I've kept `1x`/`2x`
descriptors of `srcset` (covers performance/dpi, not art-directed cases)
• I've specified (hopefully intuitive) interaction between MQs and
resolution selection to support more cases.
• Improved alternative text — allows structured fallback, avoids
duplication.
• Minimized verbosity. `picture` → `pic`, `srcset` → `src`. 2x image can
be embedded with the same number of characters as 1x `img`.
• Default resolution can be controlled with CSS `image-resolution`.
• Allowed both attribute microsyntax and nested `source`/`img`
elements. The former for brevity in common cases, and the latter for
extensibility, `width`/`height` attributes to avoid reflows and fallback
for HMTL4 UAs without repetition.
• I could not figure out powerful and clean syntax for breakpoint
macros/uri templates, so I've left that out. Hopefully it can be added
later.
##The `pic` element in examples:
pic src=image.jpg 1xalt text/pic
Same as `img src=image.jpg alt=alt text`. The `1x` means 1:1 scale
of image to CSS pixels.
pic src=small.jpg (max-width:320px), medium.jpg (max-width:768px),
large.jpgalt text/pic
Selects image to embed based on width of the viewport.
pic src=portrait.jpg (orientation:portrait), landscape.jpgalt
text/pic
Selects image based on orientation of the device.
pic src=whitebg.jpg 2x print, blackbg.jpg 1xalt text/pic
Embeds high-res image with white background when the page is printed, and
a regular-res black image otherwise.
pic src=image.jpgalt text/pic
Embeds image at 192dpi (default scaling is 2x, possible to override with
CSS).
Same as `pic src=image.jpg 2xalt text/pic` or
`img src=100x100px width=50 height=50 alt=alt text`.
pic src=image1.jpg 1x, image2.jpg 2xalt text/pic
Embeds image at either 96dpi or 192dpi, depending on capabilities and
preferences of the user agent (UA can pick any alternative).
Same as `pic src=image2.jpg 2x, image1.jpg 1xalt text/pic` and `pic
src=image2.jpg, image1.jpg 1xalt text/pic`.
pic src=small.jpg 0.5x, medium.jpg 1x, large.jpg 2x
style=width:100%alt text/pic
Selects image based on display resolution/zoom, and optionally width of
the container (if UA has layout information available when image is
[pre]loaded).
Unlike version with `min`/`max-width` media query, UA is allowed to pick
any image and dynamically change the image (e.g. prefer cached image or
download low-res first, replace with high-res when network is idle).
##(optional?) extended syntax:
pic src=a (mq), b 3xalt text/pic
is same as:
pic
source src=a media=(mq)
source src=b resolution=3x
alt text
/pic
(I'm not sure if `source` should allow microsyntax in `src` `source
src=b 3x` instead of `resolution=3x`)
The `source` element allows `width`/`height` to be specified for each
alternative:
pic
source src=large.jpg media=(min-width:1024px) width=1024
height=300
source src=medium.jpg media=(min-width:768px) width=768
height=200
img src=small.jpg width=320 height=100
alt text
/pic
An `img` element can be used in place of any `source`.
`width`/`height` defines size to display selected image at, but does not
take part in selection of alternatives.
The common syntax for use with JS polyfills is expected to be:
pic src=…noscriptimg src=… alt=…/noscript/pic
##In formal terms
The `pic` element requires closing tag. The content is interpreted as a
fallback for UAs that don't support `pic` or don't display the image
(fallback includes text in img alt inside pic).
The `src` attribute contains comma-separated list of alternative images:
src=alternative, alternative, …
and each alternative consists of space-separated:
url [resolution] [media]
The `resolution` and `media` are optional. Resolution defaults to the
value of CSS `image-resolution` property, and UA stylesheet should include:
pic {image-resolution:2dppx}
pic img {image-resolution:1dppx}
i.e. the default resolution is `2x` for `pic` and `1x` for `img`
unless author overrides the defaults with CSS.
Media query defaults to `all`.
If there are commas or backslashes in the URL they must be escaped with
`\`.
Alternatives can be specified using `source` and `img` elements in
addition to `pic src` attribute. Alternatives from `pic src` are
evaluated first.
The algorithm for finding these elements:
1. For each child element of `pic`
1. if the child element
Re: [whatwg] The pic element
Am 01.06.2012 um 07:33 schrieb Kornel Lesiński: Here's a bit of a kitchen sink solution with ideas that floated around. • I've used media queries for the art-directed use-cases, because: viewport size descriptors of srcset are confusing, limited (e.g. you can't have separate image only for print), and there must be an option to always predictably select image in conjunction with same `@media` in CSS (to adapt size of other page elements to the picture). I fully agree. • Browser-controlled resolution adaptation is good, so I've kept `1x`/`2x` descriptors of `srcset` (covers performance/dpi, not art-directed cases) • I've specified (hopefully intuitive) interaction between MQs and resolution selection to support more cases. This way it would be an open way. Either the developer let's the browser decide or he sets MQ. This is cool! • Improved alternative text — allows structured fallback, avoids duplication. This is where I do not agree. If you use MQ style with source you have a messy markup when writing alternative text inside the pic-element. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. • Minimized verbosity. `picture` → `pic`, `srcset` → `src`. 2x image can be embedded with the same number of characters as 1x `img`. • Default resolution can be controlled with CSS `image-resolution`. • Allowed both attribute microsyntax and nested `source`/`img` elements. The former for brevity in common cases, and the latter for extensibility, `width`/`height` attributes to avoid reflows and fallback for HMTL4 UAs without repetition. • I could not figure out powerful and clean syntax for breakpoint macros/uri templates, so I've left that out. Hopefully it can be added later. This should be added later but as we already figured out in CG this is not an easy matter because this is about HTML-variables – so maybe a whole other issue to target IMO. ##The `pic` element in examples: pic src=image.jpg 1xalt text/pic Same as `img src=image.jpg alt=alt text`. The `1x` means 1:1 scale of image to CSS pixels. pic src=small.jpg (max-width:320px), medium.jpg (max-width:768px), large.jpgalt text/pic Selects image to embed based on width of the viewport. pic src=portrait.jpg (orientation:portrait), landscape.jpgalt text/pic Selects image based on orientation of the device. Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic pic src=whitebg.jpg 2x print, blackbg.jpg 1xalt text/pic Embeds high-res image with white background when the page is printed, and a regular-res black image otherwise. pic src=image.jpgalt text/pic Embeds image at 192dpi (default scaling is 2x, possible to override with CSS). Same as `pic src=image.jpg 2xalt text/pic` or `img src=100x100px width=50 height=50 alt=alt text`. Why is default scaling 2x? A default image should always be @1x, right? pic src=image1.jpg 1x, image2.jpg 2xalt text/pic Embeds image at either 96dpi or 192dpi, depending on capabilities and preferences of the user agent (UA can pick any alternative). Same as `pic src=image2.jpg 2x, image1.jpg 1xalt text/pic` and `pic src=image2.jpg, image1.jpg 1xalt text/pic`. pic src=small.jpg 0.5x, medium.jpg 1x, large.jpg 2x style=width:100%alt text/pic Selects image based on display resolution/zoom, and optionally width of the container (if UA has layout information available when image is [pre]loaded). Unlike version with `min`/`max-width` media query, UA is allowed to pick any image and dynamically change the image (e.g. prefer cached image or download low-res first, replace with high-res when network is idle). ##(optional?) extended syntax: pic src=a (mq), b 3xalt text/pic is same as: pic source src=a media=(mq) source src=b resolution=3x alt text /pic Okay this makes sense. Then we would have a short-syntax and a detailed. The last one would fit for most developers. (I'm not sure if `source` should allow microsyntax in `src` `source src=b 3x` instead of `resolution=3x`) I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: source src=b media=3x The `source` element allows `width`/`height` to be specified for each alternative: pic source src=large.jpg media=(min-width:1024px) width=1024 height=300 source src=medium.jpg media=(min-width:768px) width=768 height=200 img src=small.jpg width=320 height=100 alt text /pic An `img` element can be used in place of any `source`. `width`/`height` defines size to display selected image
