I see that it is very similar to <progress>, and may be misused as a progress bar (which w3 actually even acknowledges and guides against). I wonder why one tag could not have sufficed.
The <meter> and <progress> are pretty amazing... I only wished they would settle on a standard way to style it. And if they would allow non-linear transformations (e.g. by putting cos and sin functions in the transformation matrix so it can appear like a speedometer) that would be golden.
Does lazy loading at least carve out a placeholder spot for the image so that it doesn't throw off the layout? Because if not, please use something that does.
There's nothing more frustrating than when I'm trying to read through a page and my spot keeps getting pushed up and up because of dynamically loading elements.
I believe that with current browsers the layout will change unless the width/height are specified in HTML.
That being said, lazy loading does at least some of the time work "invisibly" with images getting loaded before they would become visible. It's up to the browser to decide how aggressive it wants to be about this.
As other replies have mentioned, you need to set the width and height attributes on the img element. I believe that now works for responsive images in recent versions of popular browsers.
I've dynamically updated <datalist> on a site, only to find out that browsers will only show options that strictly begin with whatever you've typed into the <input>. When you want to do Google Search-esque suggestions, that's a problem. I don't know how to override that to force it to show all options.
There's so much stuff in HTML that's almost good enough to replace things we use Javascript for. We should also have had built-in pagination and sorting on tables, like, years ago, with some kind of (optional, if your data aren't all available on the initial page load) back-end spec for how the requests will be shaped and for delivering the data.
An awful lot of "AJAX" Javascript use could just be frames and iframes, if they were somewhat better.
Form validation should be built-in (with optional light JS for defining non-built-in validators). The browser should supply a lot more input types, including some kind of payment integration. It's absurd those things have to be built over and over and delivered by the website.
No mention of the <dialog> element [1] but that's probably because browser support isn't great—not implemented in Safari, experimental flag in Firefox.
The lazy-loading option for img elements is news to me, but I think I'd still prefer to use JavaScript for that task. Same probably goes for the dialog element actually now that I think about it.
Having a simple HTML5 option might seem cool, but I like to keep the actual logic in JavaScript and to use HTML just for page structure. Basically, I prefer to depend on HTML as little as possible for user interaction/behaviour.
HTML: what an element *is*
CSS: how an element looks
JS: what an element *does*
There's always overlap and blurred lines but that's one of the joys [2] of developing for the web.
If you're using a framework like React you don't even care about the markup, it's all abstracted away -- but in that case, you care even less about neat little HTML5 additions, you've got components and they're woven into your event dispatch and state already.
Is there any good 'linear'(with a clear learning path, e.g. course/book, as opposed to MDN) resource to learn modern HTML/CSS? Preferably not one starting at Hello World. The thing is I'm primarily a BE developer but I have to do some front-end tasks every now and then and I often catch myself reinventing the HTML5 wheel.
To build upon this question, more broadly: I'm also someone who's done quite a bit of HTML but it definitely isn't my day job. Finding good info is quite hard whenever I do want to make some site: most of the time I end up on reference pages but they don't give a good overview, whereas beginner's tutorials might have the piece of info I'm missing somewhere on the middle of part 7 (I don't have the patience for that). Searching for "modern HTML mobile scaling for someone who's about 12 years out of date please" doesn't quite seem to do it.
Does anyone have a good way to approach this? Or for HTML in particular, is there some way to keep up with it (on a decade time scale, not this year's framework hype)?
"Performance tip. You can use the loading=lazy attribute to defer the loading of the image until the user scrolls to them."
Can someone explain to me when this is useful?
As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling.
As a content creator I understand the idea that I might potentially save the consumer some bandwidth, given they might - against all odds and for whatever reason - decide not to scroll down. Kidding aside I think that as a creator I should optimize for the readers that are thoroughly interested in my whole content and therefore I should preload and not lazy load.
> As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling.
That's the experience most javascript solutions gave you. This browser native solution will load images _before_ they're visible in the viewport so you do not get the fading-in flashes you often see. Combine it with setting the width and height on an element and your page also won't shift around as you scroll.
This will actually optimize for the reader as it will improve the time it takes before they can interact with your page. I also think you'd be very disappointed if you see the percentages of people that end up scrolling on any given page.
I've been using this in a script I wrote for myself which is basically a huge image gallery. This gallery may consist of thousands of images on a single page. When the browser always had to load all of those thumbnails, it consumed a lot of bandwidth and was very slow. In fact, the user experience was strictly worse because images are normally loaded in the order they appear on the website, so it took several seconds until the thumbnails at the end of the page were available. Now the browser just loads those thumbnails that I can see (or am about to see), and they are there pretty much instantly even if I scroll to the end of my gallery.
It's a longish travel report, lots of photos, interspersed with comments. I think it might be nice not to have all of them loaded in the beginning. Especially since random visitors probably won't read it till the end.
#1, images that load only when they scroll into view, bother the hell of out me. I doubt there's a website that enabled this where I haven't noticed the constant flashing of content as I scroll down. Looks rather glitchy and constantly distracting from the text you're reading.
Luckily not that many sites have it, but come to think of it, does anyone know of an add-on or something to disable the lazy attribute?
first of all that is not limited to those kinds of links, generally, in Windows this used to be handled by registering a uri scheme in the registry and associating it with an application for handling that uri scheme, mac has a similar method https://kaihao.dev/posts/Make-your-own-custom-URI-scheme-res...
so you can use any uri scheme, magnet links etc. in a link, you can also do stuff with JavaScript with those uri schemes, for example window.location = "tel:some telephone number you want to call".
Nowadays if you have not used a uri scheme in a browser on a particular OS and you click on a tel:phone number link you will end up getting asked if you want to associate links of type tel with a particular application for handling it (assuming you have a handler for tel uri scheme on your OS - on mine it asked me if I wanted to open with FaceTime, as I am on Mac). It used to be that it would just open whatever application was associated with the scheme. I guess it is a security measure.
So you could theoretically end up in a situation where someone does not have a handler for a scheme you are using to make a link. If you want to avoid this for tel and sms links detect if the user is on a phone of some sort because of course those will have handlers for tel and sms built in. Otherwise you need to take your chances.
I wish the <progress> tag receuves some love, from both users and browsers.
I recently worked on a page (e.g https://php.watch/rfcs/fibers) that I didn't want to set inline CSS to set a dynamic width for an element. Helps me not use a strict CSP.
I kind of abused the progress element because it has customizable width. Elements that support a width attribute (object, iframe, image, etc) didn't fit that well. Progress elements are pretty nice, supported almost everywhere it mattered to my audience, and with some pseudo properties I never heard before, I could customize the colors and other properties as well.
I agree. A couple of years ago I answered an SO question about how to style a <meter> tag cross browser[1]. It is kind of ridiculous the amount of vendor prefix one must use to achieve this. At this point I would even just settle on a standard so that I could have autoprefixer do this for me.
Also both <progress> and <meter> would be an order of magnitute more usable if non-linear functions (such as sin(), cos(), pow(), exp(), etc.) were allowed as values in CSS transformation matrices so that I could use <meter> instead of <svg> when my designer wants the meter bar to look like a speedometer (which is a quite common, and a valid design choice).
Some remarks, with some opinions, some caveats, and some extra info that I find interesting:
1. Lazy loading: generally speaking, just don’t do this. It’s much better than doing it in JavaScript (especially when combined with a blurry image until it loads, which I and many others find surprisingly disconcerting), but if you’re not very close to the server (which very commonly means “if you’re not in the USA”) then it commonly just means that the images won’t be loaded when you scroll to them. Also there’s the whole load-the-page-then-go-offline problem, which I feel is more common than most realise. Instead, I say: if you care about the image, you very probably shouldn’t use lazy loading on it; and if you don’t care about it, hey, why not just remove it?
2. Telephone and SMS links: the unfortunate trouble with these is that you can’t detect whether they’ll work or not. If they don’t work, they’ll probably just mysteriously do nothing, and you can’t reliably detect that, because your code may not be able to detect if it did do something. This is all just something to be aware of.
4. The <meter> element: see also the <progress> element. Two similar elements that differ in semantics as to which you should use.
6. Fieldset Element: a point in the demo that’s not ideal is that the gap between the radio button and the label isn’t clickable. One way of fixing most of this is to start the label immediately after the radio button, with the leading whitespace inside it rather than before it. But depending on user agent and content styles, even that may well be insufficient, leaving a tiny gap. In a situation like this, the ideal is to put the radio button inside its label, and make the label `display: block`, or something else that achieves this effect (if done carefully, you might even find `display: grid` suitable nowadays).
7. window.opener: it suggests including rel="noopener" or rel="noreferrer" in order to remove the opener; I think it’s worth noting for explanation that noreferrer implies noopener (because you could access the referrer through the opener): https://html.spec.whatwg.org/multipage/links.html#link-type-....
10. The `spellcheck` attribute: this is actually a tristate attribute: it has states true, false, and default (which mostly means “inherit”). `spellcheck="true"` can be written more briefly as just `spellcheck` (which, in the HTML syntax, is equivalent to `spellcheck=""`). See https://html.spec.whatwg.org/multipage/interaction.html#attr... for more info.
12. HTML Accordion: I have just two general remarks on web design here. ① If you’re using something like this for FAQs, please strongly consider not using an accordion, but instead having a table of contents with links to each question, followed by the questions (as headings) and answers (as paragraphs); or if you’re not willing to do that, please provide an “expand all” button through JavaScript. ② On the web, accordions have historically regularly been implemented so that at most one item of any set will be open: that opening another closes any that was open. Please don’t do this. It’s a pain. I just want to read stuff, I don’t want to have to interact further. (See also my “expand all” request in part one.)
14. `download` attribute: this can also take a value, which will be used as the filename. This is useful if you generate a file client-side as a data: URI. It’s not so useful outside that, actually, as you’re probably better to get the server to set the filename via the content-disposition header, or if you’re generating a file client-side with a blob: URI, use File instead of Blob so that you can set the filename.
15. .webp: significantly overrated, in my opinion. It doesn’t give anywhere near as big a boost in compression relative to properly-done JPEG as people think (like under 10% a lot of the time). Now AVIF, that’s another matter.
16? Video thumbnail: an interesting thing that has just occurred to me on this is that the poster attribute doesn’t let you provide multiple formats like <picture> does. Hmm, so you probably keep serving a JPEG here instead of WebP, AVIF or whatever else. Wonder if anything can ever be done about that. I can imagine them making poster="#foo" followed by <picture id="foo"> inside the <video> work. Eek, this similarity to svg:use made me realise that you can actually achieve this goal with SVG already: the code below ought to do it; ugh!
> 15. .webp: significantly overrated, in my opinion. It doesn’t give anywhere near as big a boost in compression relative to properly-done JPEG as people think (like under 10% a lot of the time). Now AVIF, that’s another matter.
I was saying the same thing but then I realized something. The thing about webp isn't about how it compares to jpg[0]. Png on the other hand, with all those logos and some with transparency. Webp can replace these with only a fraction of png-size.
Anything photographic, where quality is priority and transparency isn't required I find jpg to be finer quality.
Lately I've been a fan of lazy preloading. First I just load the requested page and all resources on it. Then, if javascript is enabled, I start loading the rest of the site (or section of the site) into hidden dom elements, starting with the resources most likely to be requested next. Then the rest of the user's interactions on the site are near-instant and you can even bring the entire thing offline.
Regarding lazy image loading, I'm not a fan of these wholesale opinions that don't consider how varied our needs are. I'm showing a gallery of photo thumbnails going back a decade.
I want to provide a smooth experience similar to how you'd watch your gallery on Android or iOS.
So this means no, I don't want to have the user click links with years and months on them, I want a single page.
But do I want to load literally THOUSANDS OF IMAGES at once? No.
I want to know where on the page I am, and load the visible images, and also few rows above the fold and few rows below the fold.
And I can do this with JS.
What's the lesson here? "They won't be loaded when you scroll anyway". They can be. "HTML is much better than JavaScript" sometimes (often) it isn't. "if you care about the image, you very probably shouldn’t use lazy loading on it; and if you don’t care about it, hey, why not just remove it?" Well, BS.
> In a situation like this, the ideal is to put the radio button inside its label, and make the label `display: block`, or something else that achieves this effect (if done carefully, you might even find `display: grid` suitable nowadays).
This is actually not great for accessibility. It may be okay for some screen readers if you also populate the for/id attributes, but even then you should test to be sure.
Edit to add:
> Video thumbnail: an interesting thing that has just occurred to me on this is that the poster attribute doesn’t let you provide multiple formats like <picture> does. Hmm, so you probably keep serving a JPEG here instead of WebP, AVIF or whatever else. Wonder if anything can ever be done about that. I can imagine them making poster="#foo" followed by <picture id="foo"> inside the <video> work. Eek, this similarity to svg:use made me realise that you can actually achieve this goal with SVG already: the code below ought to do it; ugh!
My solution is to skip the poster attribute and use a picture with object-fit: cover.
14. `download` attribute: this can also take a value, which will be used as the filename. This is useful if you generate a file client-side as a data: URI.
Awesome list! The '<ol> tip reminds me that I wish there was a better way to do nested list numbering of the kind you'd likely find in a table of contents, such as "1.1.2" and so on. As far as I'm aware there's no simple way to do this natively without using CSS or JS to change the list item prefix.
Doesn't seem to always work for me on Edge: the spinner spins, sometimes I get the autocompletion window, others I don't, or I need to focus the input again for it to appear.
Which is consistent with the experience I had with the native search widget in this article. I guess nobody uses it, so it's full of bugs and UX issues.
It’s probably also worth mentioning in the section about image performance:
1. The source element also accepts a media attribute with the same syntax as CSS media queries; the first match (media + type) wins, so typical usage is largest > smallest. If you enlarge the window it’ll automatically load larger images. (Annoyingly, this is not supported on video>source.)
- When styling picture elements in CSS, you actually need to select the img tag. This still trips me up time to time.
Very nice list. TIL amount meter and datalist. One remark, if your first point explains lazy loading, your intro does not need to explain what HTML is.
[+] [-] tylerscott|4 years ago|reply
I wonder what else in the HTML5 spec I've missed...
Thanks for sharing this!
[+] [-] iib|4 years ago|reply
[+] [-] runarberg|4 years ago|reply
[+] [-] mdenic|4 years ago|reply
[+] [-] AdmiralAsshat|4 years ago|reply
There's nothing more frustrating than when I'm trying to read through a page and my spot keeps getting pushed up and up because of dynamically loading elements.
[+] [-] dynm|4 years ago|reply
That being said, lazy loading does at least some of the time work "invisibly" with images getting loaded before they would become visible. It's up to the browser to decide how aggressive it wants to be about this.
[+] [-] tshaddox|4 years ago|reply
It used to not work for responsive images. We had to do tricks like pseudo elements with padding set to a percent value: https://css-tricks.com/preventing-content-reflow-from-lazy-l...
[+] [-] poniko|4 years ago|reply
[+] [-] jontro|4 years ago|reply
[+] [-] austincheney|4 years ago|reply
[+] [-] theandrewbailey|4 years ago|reply
I've dynamically updated <datalist> on a site, only to find out that browsers will only show options that strictly begin with whatever you've typed into the <input>. When you want to do Google Search-esque suggestions, that's a problem. I don't know how to override that to force it to show all options.
[+] [-] intergalplan|4 years ago|reply
An awful lot of "AJAX" Javascript use could just be frames and iframes, if they were somewhat better.
Form validation should be built-in (with optional light JS for defining non-built-in validators). The browser should supply a lot more input types, including some kind of payment integration. It's absurd those things have to be built over and over and delivered by the website.
I could go on. It's a damn shame.
[+] [-] jnellis|4 years ago|reply
[+] [-] asddubs|4 years ago|reply
[+] [-] wanda|4 years ago|reply
The lazy-loading option for img elements is news to me, but I think I'd still prefer to use JavaScript for that task. Same probably goes for the dialog element actually now that I think about it.
Having a simple HTML5 option might seem cool, but I like to keep the actual logic in JavaScript and to use HTML just for page structure. Basically, I prefer to depend on HTML as little as possible for user interaction/behaviour.
There's always overlap and blurred lines but that's one of the joys [2] of developing for the web.If you're using a framework like React you don't even care about the markup, it's all abstracted away -- but in that case, you care even less about neat little HTML5 additions, you've got components and they're woven into your event dispatch and state already.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
[2]: horrors
[+] [-] didymospl|4 years ago|reply
[+] [-] lucb1e|4 years ago|reply
Does anyone have a good way to approach this? Or for HTML in particular, is there some way to keep up with it (on a decade time scale, not this year's framework hype)?
[+] [-] weinzierl|4 years ago|reply
"Performance tip. You can use the loading=lazy attribute to defer the loading of the image until the user scrolls to them."
Can someone explain to me when this is useful?
As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling.
As a content creator I understand the idea that I might potentially save the consumer some bandwidth, given they might - against all odds and for whatever reason - decide not to scroll down. Kidding aside I think that as a creator I should optimize for the readers that are thoroughly interested in my whole content and therefore I should preload and not lazy load.
[+] [-] kilian|4 years ago|reply
That's the experience most javascript solutions gave you. This browser native solution will load images _before_ they're visible in the viewport so you do not get the fading-in flashes you often see. Combine it with setting the width and height on an element and your page also won't shift around as you scroll.
This will actually optimize for the reader as it will improve the time it takes before they can interact with your page. I also think you'd be very disappointed if you see the percentages of people that end up scrolling on any given page.
[+] [-] TonyTrapp|4 years ago|reply
[+] [-] Tomte|4 years ago|reply
It's a longish travel report, lots of photos, interspersed with comments. I think it might be nice not to have all of them loaded in the beginning. Especially since random visitors probably won't read it till the end.
[+] [-] FriedrichN|4 years ago|reply
[+] [-] martijn_himself|4 years ago|reply
[+] [-] tyingq|4 years ago|reply
Now I can have proper zero indexed lists and annoy friends. Chrome even supports negative integers.
[+] [-] bigiain|4 years ago|reply
<ol start="0.5">
Is not supported...
[+] [-] lucb1e|4 years ago|reply
Luckily not that many sites have it, but come to think of it, does anyone know of an add-on or something to disable the lazy attribute?
[+] [-] bryanrasmussen|4 years ago|reply
first of all that is not limited to those kinds of links, generally, in Windows this used to be handled by registering a uri scheme in the registry and associating it with an application for handling that uri scheme, mac has a similar method https://kaihao.dev/posts/Make-your-own-custom-URI-scheme-res...
it used to be that Linux didn't have a way to handle uri schemes (like back in 2006), but it seems to no longer be the case https://unix.stackexchange.com/questions/497146/create-a-cus...
so you can use any uri scheme, magnet links etc. in a link, you can also do stuff with JavaScript with those uri schemes, for example window.location = "tel:some telephone number you want to call".
Nowadays if you have not used a uri scheme in a browser on a particular OS and you click on a tel:phone number link you will end up getting asked if you want to associate links of type tel with a particular application for handling it (assuming you have a handler for tel uri scheme on your OS - on mine it asked me if I wanted to open with FaceTime, as I am on Mac). It used to be that it would just open whatever application was associated with the scheme. I guess it is a security measure.
So you could theoretically end up in a situation where someone does not have a handler for a scheme you are using to make a link. If you want to avoid this for tel and sms links detect if the user is on a phone of some sort because of course those will have handlers for tel and sms built in. Otherwise you need to take your chances.
on edit: a not very great article I wrote on this subject in 2003 http://www.devx.com/webdev/Article/17120
[+] [-] Ayesh|4 years ago|reply
I recently worked on a page (e.g https://php.watch/rfcs/fibers) that I didn't want to set inline CSS to set a dynamic width for an element. Helps me not use a strict CSP.
I kind of abused the progress element because it has customizable width. Elements that support a width attribute (object, iframe, image, etc) didn't fit that well. Progress elements are pretty nice, supported almost everywhere it mattered to my audience, and with some pseudo properties I never heard before, I could customize the colors and other properties as well.
[+] [-] runarberg|4 years ago|reply
Also both <progress> and <meter> would be an order of magnitute more usable if non-linear functions (such as sin(), cos(), pow(), exp(), etc.) were allowed as values in CSS transformation matrices so that I could use <meter> instead of <svg> when my designer wants the meter bar to look like a speedometer (which is a quite common, and a valid design choice).
1: https://stackoverflow.com/questions/8094835/how-to-style-htm...
[+] [-] chrismorgan|4 years ago|reply
1. Lazy loading: generally speaking, just don’t do this. It’s much better than doing it in JavaScript (especially when combined with a blurry image until it loads, which I and many others find surprisingly disconcerting), but if you’re not very close to the server (which very commonly means “if you’re not in the USA”) then it commonly just means that the images won’t be loaded when you scroll to them. Also there’s the whole load-the-page-then-go-offline problem, which I feel is more common than most realise. Instead, I say: if you care about the image, you very probably shouldn’t use lazy loading on it; and if you don’t care about it, hey, why not just remove it?
2. Telephone and SMS links: the unfortunate trouble with these is that you can’t detect whether they’ll work or not. If they don’t work, they’ll probably just mysteriously do nothing, and you can’t reliably detect that, because your code may not be able to detect if it did do something. This is all just something to be aware of.
4. The <meter> element: see also the <progress> element. Two similar elements that differ in semantics as to which you should use.
6. Fieldset Element: a point in the demo that’s not ideal is that the gap between the radio button and the label isn’t clickable. One way of fixing most of this is to start the label immediately after the radio button, with the leading whitespace inside it rather than before it. But depending on user agent and content styles, even that may well be insufficient, leaving a tiny gap. In a situation like this, the ideal is to put the radio button inside its label, and make the label `display: block`, or something else that achieves this effect (if done carefully, you might even find `display: grid` suitable nowadays).
7. window.opener: it suggests including rel="noopener" or rel="noreferrer" in order to remove the opener; I think it’s worth noting for explanation that noreferrer implies noopener (because you could access the referrer through the opener): https://html.spec.whatwg.org/multipage/links.html#link-type-....
10. The `spellcheck` attribute: this is actually a tristate attribute: it has states true, false, and default (which mostly means “inherit”). `spellcheck="true"` can be written more briefly as just `spellcheck` (which, in the HTML syntax, is equivalent to `spellcheck=""`). See https://html.spec.whatwg.org/multipage/interaction.html#attr... for more info.
12. HTML Accordion: I have just two general remarks on web design here. ① If you’re using something like this for FAQs, please strongly consider not using an accordion, but instead having a table of contents with links to each question, followed by the questions (as headings) and answers (as paragraphs); or if you’re not willing to do that, please provide an “expand all” button through JavaScript. ② On the web, accordions have historically regularly been implemented so that at most one item of any set will be open: that opening another closes any that was open. Please don’t do this. It’s a pain. I just want to read stuff, I don’t want to have to interact further. (See also my “expand all” request in part one.)
14. `download` attribute: this can also take a value, which will be used as the filename. This is useful if you generate a file client-side as a data: URI. It’s not so useful outside that, actually, as you’re probably better to get the server to set the filename via the content-disposition header, or if you’re generating a file client-side with a blob: URI, use File instead of Blob so that you can set the filename.
15. .webp: significantly overrated, in my opinion. It doesn’t give anywhere near as big a boost in compression relative to properly-done JPEG as people think (like under 10% a lot of the time). Now AVIF, that’s another matter.
16? Video thumbnail: an interesting thing that has just occurred to me on this is that the poster attribute doesn’t let you provide multiple formats like <picture> does. Hmm, so you probably keep serving a JPEG here instead of WebP, AVIF or whatever else. Wonder if anything can ever be done about that. I can imagine them making poster="#foo" followed by <picture id="foo"> inside the <video> work. Eek, this similarity to svg:use made me realise that you can actually achieve this goal with SVG already: the code below ought to do it; ugh!
———If you enjoyed this article, see also https://markodenic.com/css-tips/ from the same author on CSS tips, discussed here nine days ago at https://news.ycombinator.com/item?id=26945263.
[+] [-] Jiocus|4 years ago|reply
I was saying the same thing but then I realized something. The thing about webp isn't about how it compares to jpg[0]. Png on the other hand, with all those logos and some with transparency. Webp can replace these with only a fraction of png-size.
Anything photographic, where quality is priority and transparency isn't required I find jpg to be finer quality.
[0] Altough that's often the narrative.
[+] [-] c22|4 years ago|reply
[+] [-] slver|4 years ago|reply
I want to provide a smooth experience similar to how you'd watch your gallery on Android or iOS.
So this means no, I don't want to have the user click links with years and months on them, I want a single page.
But do I want to load literally THOUSANDS OF IMAGES at once? No.
I want to know where on the page I am, and load the visible images, and also few rows above the fold and few rows below the fold.
And I can do this with JS.
What's the lesson here? "They won't be loaded when you scroll anyway". They can be. "HTML is much better than JavaScript" sometimes (often) it isn't. "if you care about the image, you very probably shouldn’t use lazy loading on it; and if you don’t care about it, hey, why not just remove it?" Well, BS.
[+] [-] eyelidlessness|4 years ago|reply
This is actually not great for accessibility. It may be okay for some screen readers if you also populate the for/id attributes, but even then you should test to be sure.
Edit to add:
> Video thumbnail: an interesting thing that has just occurred to me on this is that the poster attribute doesn’t let you provide multiple formats like <picture> does. Hmm, so you probably keep serving a JPEG here instead of WebP, AVIF or whatever else. Wonder if anything can ever be done about that. I can imagine them making poster="#foo" followed by <picture id="foo"> inside the <video> work. Eek, this similarity to svg:use made me realise that you can actually achieve this goal with SVG already: the code below ought to do it; ugh!
My solution is to skip the poster attribute and use a picture with object-fit: cover.
[+] [-] zamadatix|4 years ago|reply
Now there is one I can't believe I missed.
[+] [-] pmlnr|4 years ago|reply
[+] [-] livinginfear|4 years ago|reply
[+] [-] extra88|4 years ago|reply
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Lists_a...
[+] [-] marcosdumay|4 years ago|reply
[+] [-] gfiorav|4 years ago|reply
https://beachboyslegacy.com
[+] [-] 1_player|4 years ago|reply
Which is consistent with the experience I had with the native search widget in this article. I guess nobody uses it, so it's full of bugs and UX issues.
[+] [-] pluppen|4 years ago|reply
[+] [-] eyelidlessness|4 years ago|reply
1. The source element also accepts a media attribute with the same syntax as CSS media queries; the first match (media + type) wins, so typical usage is largest > smallest. If you enlarge the window it’ll automatically load larger images. (Annoyingly, this is not supported on video>source.)
- When styling picture elements in CSS, you actually need to select the img tag. This still trips me up time to time.
[+] [-] yummybear|4 years ago|reply
[+] [-] ilkka_es|4 years ago|reply
[+] [-] tommek4077|4 years ago|reply
Frontend devs not knowing HTML, but having complicated and over engineered build pipelines and continous integration for their JS cruft.
I wonder why sites don't load faster or render... ah right Javascript in the mega bytes.
[+] [-] mdenic|4 years ago|reply
[+] [-] yoz-y|4 years ago|reply
[+] [-] rammy1234|4 years ago|reply