HTML Tips (2020)(markodenic.com)
markodenic.com
HTML Tips (2020)
https://markodenic.com/posts/html-tips/
135 comments
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.
<meter> allows you to define an optimal and a sub-optimal value, such that a full meter might be bad (or good) depending on where the value lands relative to it.
Although, one could argue that a <progress> is just a <meter> where the optimal value is 100%.
Although, one could argue that a <progress> is just a <meter> where the optimal value is 100%.
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.
Glad you enjoyed it.
Hey Marko, thank you for this resource! As somebody who is teaching themselves full-stack development, it's easy to miss out on learning tips and tricks like these. This is very useful. I'm going to link to your webpage in the first ever item on my new TIL page (https://news.ycombinator.com/item?id=27017604).
Awesome! Thanks.
Great stuff Marco thanks!
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.
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.
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.
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...
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...
its a bit flaky, sometimes it just does not work, and its hard to debug, css is a hard language to debug and get right.
https://jaeh.at works fine when reloading, no layout changes, and the layout changed slightly before i fixed it using width & height.
https://noncon.org does not (and i had no time to fix, might be because width of images is not set, might be something with the css position/float layout, we had about a week to setup the whole conference infrastructure, including the streaming server, layout flashing was my last concern at the time and i kept myself too busy since then to fix something so trivial...)
sorry for the personal links, just examples i knew from the top of my head because i built them ;)
https://jaeh.at works fine when reloading, no layout changes, and the layout changed slightly before i fixed it using width & height.
https://noncon.org does not (and i had no time to fix, might be because width of images is not set, might be something with the css position/float layout, we had about a week to setup the whole conference infrastructure, including the streaming server, layout flashing was my last concern at the time and i kept myself too busy since then to fix something so trivial...)
sorry for the personal links, just examples i knew from the top of my head because i built them ;)
Oh yes it does, you need to specify width and height for it to work properly.
Currently loading="lazy" is not supported by safari https://caniuse.com/loading-lazy-attr
If you know the size of the incoming image specify its dimensions with CSS.
> 5. HTML Native Search
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.
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.
I could go on. It's a damn shame.
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.
The HTML form <input> element has a lot of interactive controls already e.g. colour picker, a date control for entering dates, file picker, number entry with spinner controls and more:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
The problem is that some HTML form controls cannot be styled with CSS to render consistently across browsers. So, many sites fall back on JavaScript to render the control. Here is an example from 2016 on styling HTML checkboxes and radio buttons to make them larger (which, as far I can tell, is still a problem): https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
The problem is that some HTML form controls cannot be styled with CSS to render consistently across browsers. So, many sites fall back on JavaScript to render the control. Here is an example from 2016 on styling HTML checkboxes and radio buttons to make them larger (which, as far I can tell, is still a problem): https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-...
Date pickers and color pickers don't have to be consistent across desktop/tablet/mobile/kiosk/etc. They just have to be consistent across sites, but on the same device.
On Firefox, the date picker is good and I can easily navigate to a year from muscle memory. The same wouldn't work on mobile, so they have different UI and controls. I don't want to use iOS style date pickers on my Android, or the other way around just for consistency.
Many custom date pickers are sluggish and has bad UX, and adds a lot of extra validation complexity with pseudo elements.
On Firefox, the date picker is good and I can easily navigate to a year from muscle memory. The same wouldn't work on mobile, so they have different UI and controls. I don't want to use iOS style date pickers on my Android, or the other way around just for consistency.
Many custom date pickers are sluggish and has bad UX, and adds a lot of extra validation complexity with pseudo elements.
And also cross browser support for the spec in general - eg desktop Safari doesn't implement that date picker, or any special treatment of input type="date" at all.
Apparently it will be supported in the next version!
https://webkit.org/blog/11648/new-webkit-features-in-safari-...
In fact, Safari 14.1 is current as of last week (well, this week...) https://support.apple.com/en-us/HT212340
And iOS 14.5 (well, 14.5.1) is also current: https://support.apple.com/en-ca/HT211808#1451
But we'll have to wait a few weeks to months before all Safari users upgrade and see the latest improvements.
And iOS 14.5 (well, 14.5.1) is also current: https://support.apple.com/en-ca/HT211808#1451
But we'll have to wait a few weeks to months before all Safari users upgrade and see the latest improvements.
Yes, but still I think it's great news as it looks like we can realistically make forms using native inputs only and validation, complex inputs (like date pickers) all can be setup with little to no javascript. This enables much simpler architectures, like traditional server side rendered apps, that still have a great UX.
I don't have a modern Safari in front of me to check, but Can I Use alleges they're about on par with Firefox as of 14.1: https://caniuse.com/?search=Input%20date
Does that mean only fully up-to-date macOS gets it, or do Safari versions move independent of the OS?
Does that mean only fully up-to-date macOS gets it, or do Safari versions move independent of the OS?
Current Safari is available on at least two previous versions.
In rare cases, Safari features require a capability only available on the latest macOS.
In rare cases, Safari features require a capability only available on the latest macOS.
In Python there's a saying: the standard library is where modules go to die. That effect applies even more so for browser builtins.
IMO we would be better off moving most of these things out of the browsers and into some kind of web component standard.
IMO we would be better off moving most of these things out of the browsers and into some kind of web component standard.
Yeah, I’ve long thought that the model of a relatively sparse standard library in a sufficiently expressive language is the ideal. What’s really needed is a newspeak-style parameterized “push” module system (or ML functors) to replace “pull”-style imports.
This way, modules can declare that they need certain functionality and then the end user provides it: instead of npm-style infinitely-deep dependency trees.
https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1
https://wiki.c2.com/?BanOnImports
This way, modules can declare that they need certain functionality and then the end user provides it: instead of npm-style infinitely-deep dependency trees.
https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1
https://wiki.c2.com/?BanOnImports
no way, browsers have a stacked deck especially in regards to accessibility, but also things like platform appropriateness and handling corner cases that only affect specific scenarios. web components tend to be the 80% that whoever made them cared about, which varies from use case to use case.
It's also because Python has such an awesome stdlib that it's so popular. So there is that.
> Form validation should be built-in
Have you used pattern attributes?
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
Have you used pattern attributes?
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
I know it uses JS but the customValidity stuff is pretty cool too!
Yes! That is definitely a big step in the right direction. It's usually enough to remove at least some of the JS burden on forms. I'm not sure how widespread its use is in practice, though.
drag and drop rearrangeable lists as a form element!
Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost in time and ongoing overhead in time & bugs for everydamnthing else added to the UI after. I've seen business-side people favor terrible products because they have drag-n-drop, while a better alternative doesn't. They love it.
It's heavy-weight, fragile, lots of implementations are framework-specific, and most of them are horribly buggy, but it's nonetheless a must-have feature in many cases. It'd be a great candidate for better support in the browser, generally, if we're going to insist on using it as an application platform.
It's heavy-weight, fragile, lots of implementations are framework-specific, and most of them are horribly buggy, but it's nonetheless a must-have feature in many cases. It'd be a great candidate for better support in the browser, generally, if we're going to insist on using it as an application platform.
> Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost
This just made me laugh because it is so true. I thought it was just my stupid luck that I keep working with companies obsessed with drag and drop. But you are right. I have seen companies blow hundreds of thousands of dollars implementing drag and drop on a trivial feature. The same company will then complain about spending a few thousand dollars implementing a security feature or implementing training programs to teach employees about the importance of securely handling PII.
Edit: PII = Personal Identifiable Information (social security numbers, credit cards, birthdates, etc).
This just made me laugh because it is so true. I thought it was just my stupid luck that I keep working with companies obsessed with drag and drop. But you are right. I have seen companies blow hundreds of thousands of dollars implementing drag and drop on a trivial feature. The same company will then complain about spending a few thousand dollars implementing a security feature or implementing training programs to teach employees about the importance of securely handling PII.
Edit: PII = Personal Identifiable Information (social security numbers, credit cards, birthdates, etc).
Has this improved? I've seen recently browser built in drag and drop (that people don't use as of, but as a base in lightweight dnd librairies).
I don't remember having that last time I had to implement serious drag and drop, about 4 years ago.
I don't remember having that last time I had to implement serious drag and drop, about 4 years ago.
Drag and drop is not actually very usable. It's nice to have it as an option, but the main approach to rearrangeable lists should just be a list widget w/ selectable items and [↑] [↓] buttons to shift the currently-selected entry upwards or downwards.
I strongly disagree. It’s the most natural thing in the world for GUI/mouse users to drag-n-drop objects. It’s even nice for touch with the right OS/hardware support.
You are confusing "usable" with "intuitive".
You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use.
But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for them or might not work at all. It might be INTUITIVE on what the user is supposed to do, but it isn't USABLE. We have all encountered non-usable interfaces that we simply can not interact with for various reasons. This also becomes a concern for accessibility. A screen reader may not be able to read it to someone who is blind. An older device might not be able to display or operate the drag-able functionality. A user that relies on something like "Voice Control" may not be able to use your drag-and-drop system.
Ideally you would do both. You could show an interface that has up and down arrows for each item to move items manually. But also make those elements drag-able if users choose that option. But this takes more and more development time. That is the constant battle between software engineers and decision makers. Anything is possible with enough development time, but decision makers are quick to move developers along when the item is "good enough", which generally means the feature works on the decision-maker's devices.
You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use.
But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for them or might not work at all. It might be INTUITIVE on what the user is supposed to do, but it isn't USABLE. We have all encountered non-usable interfaces that we simply can not interact with for various reasons. This also becomes a concern for accessibility. A screen reader may not be able to read it to someone who is blind. An older device might not be able to display or operate the drag-able functionality. A user that relies on something like "Voice Control" may not be able to use your drag-and-drop system.
Ideally you would do both. You could show an interface that has up and down arrows for each item to move items manually. But also make those elements drag-able if users choose that option. But this takes more and more development time. That is the constant battle between software engineers and decision makers. Anything is possible with enough development time, but decision makers are quick to move developers along when the item is "good enough", which generally means the feature works on the decision-maker's devices.
that just sounds all the more reason for a drag and drop thing to be implemented as a standard form element, that way browsers/screen readers can provide an accessibility fallback. whereas with javascript widgets, that's unlikely to happen quite often. and people are going to do drag and drop interfaces no matter what
Is that only an artifact of dynamically updating them? Firefox and chrome do as expected in the example; match any substring.
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.
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
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*
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
I’d argue that image lazy loading isn’t really a thing an image does, it’s a browser optimisation for asset loading. The built in functionality ensures the image is loaded well before it appears on the screen.
> Basically, I prefer to depend on HTML as little as possible for user interaction/behaviour.
I prefer to depend on the user agent for user interaction and behavior. Javascript and all its potential for tracking, malware, side channel exploits, etc. should be abolished from the safe web.
I prefer to depend on the user agent for user interaction and behavior. Javascript and all its potential for tracking, malware, side channel exploits, etc. should be abolished from the safe web.
> 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.
There is a polyfill that makes it works even on IE.
I embraced and use it on a product that it's remaking&modernizing all the frontend. Sadly, when I take the decision a few years ago, I thought that <dialog> would be supported for all browsers, but looks that adoption has been paralyzed.
There is a polyfill that makes it works even on IE.
I embraced and use it on a product that it's remaking&modernizing all the frontend. Sadly, when I take the decision a few years ago, I thought that <dialog> would be supported for all browsers, but looks that adoption has been paralyzed.
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)?
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)?
I’ve been skimming this book called “Learning Web Design (5th Edition)” and it does a good job at that by including sections on the big picture and long term trends.
Its author has been in the web dev field for decades and has written multiple books on the topic. She has got some chapters written by experts in respective fields (CSS by Eric Meyer and so on)
Its author has been in the web dev field for decades and has written multiple books on the topic. She has got some chapters written by experts in respective fields (CSS by Eric Meyer and so on)
John Duckett's book "HTML & CSS" is good. You can skip to the more advanced chapters if you don't want to start from zero.
As much as W3Schools is hated, I find their HTML/CSS/JS guides to be a lot simpler to understand than MDN: https://www.w3schools.com/html/default.asp
As much as W3Schools is hated, I find their HTML/CSS/JS guides to be a lot simpler to understand than MDN: https://www.w3schools.com/html/default.asp
Thanks everyone for all the recommendations. I need more time to look into them but I just wanted to add here that the book you mentioned [1] stands out as one of the most aesthetically pleasing IT books I've seen.
[1] http://www.htmlandcssbook.com/
[1] http://www.htmlandcssbook.com/
Doesn't necessarily mean anything, but I checked out the book on Amazon and see that:
Publisher : John Wiley & Sons; 1st edition (November 8, 2011)
I am sure there are a lot of good stuff there, but quite a lot has happened with html/css and browser support since late 2011.
I am sure there are a lot of good stuff there, but quite a lot has happened with html/css and browser support since late 2011.
Not linear but I recommend: for HTML read chapter 3 & 4 of HTML spec - https://html.spec.whatwg.org/
For CSS I recommend Wes Bos tutorials about flexbox and grid - https://wesbos.com/courses and this blog: https://ishadeed.com/articles/
For CSS I recommend Wes Bos tutorials about flexbox and grid - https://wesbos.com/courses and this blog: https://ishadeed.com/articles/
Thanks for the pointers!
YouTube, NetNinja had great courses that are real easy to follow.
Also read MDN often.
Also read MDN often.
Very first tip:
"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.
"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.
It's more about saving bandwidth on the server side, plus it allows for tracking without using JS.
To mitigate the tracking problem, Firefox only defers loading of images when JS is enabled: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
Chrome seemed to behave this way as well when I tested it a while ago. It's covered in the spec: https://html.spec.whatwg.org/multipage/urls-and-fetching.htm...
Chrome seemed to behave this way as well when I tested it a while ago. It's covered in the spec: https://html.spec.whatwg.org/multipage/urls-and-fetching.htm...
On the client side too. I use it to avoid loading below-the-fold images until it's necessary. For example, I don't load the thumbnails of related articles.
It makes a non-negligible impact on bandwidth usage and page load time.
It makes a non-negligible impact on bandwidth usage and page load time.
Exactly this. It's a problem already solved by pagination - but I guess that's not cool and doesn't allow for such granular tracking.
This was my thought exactly. It's infuriating and unnecessary.
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.
When I read that tip I was thinking whether I should use it on https://www.2uo.de/russland-2013/
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.
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.
Ideal in this case might be to load images that are within one or two screenfuls of the current position, then someone scrolling down actually ingesting the content might not be bothered by the delay as they probably won't see it. That would require JS though, and you need to deal with page resizes as well as scroll events. Also make sure you include width & height settings for the image tag or you scroll position reference will be off when considering images further down the page. Maybe load a low-res placeholder for the other images in case the user drops offline as they scroll, either an "image not loaded" marker just so they know something _should_ be there or a very compressed version of the actual photo.
> 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.
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.
Didn't know about <ol start="<number>">
Now I can have proper zero indexed lists and annoy friends. Chrome even supports negative integers.
Now I can have proper zero indexed lists and annoy friends. Chrome even supports negative integers.
Sadly, it appears that the logical starting index compromise between the zero index and one index factions doesn't work.
<ol start="0.5">
Is not supported...
<ol start="0.5">
Is not supported...
#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?
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?
In Firefox you can set "dom.image-lazy-loading.enabled" to false in about:config.
In Chromium based browsers set "Enable lazy image loading" to disabled in about:config
In Safari it's still an experimental feature you have to enable manually.
.
Of course since Safari doesn't support it yet plenty of sites lazy load via classic JS style solutions and trying to fix those is like playing whack-a-mole.
In Chromium based browsers set "Enable lazy image loading" to disabled in about:config
In Safari it's still an experimental feature you have to enable manually.
.
Of course since Safari doesn't support it yet plenty of sites lazy load via classic JS style solutions and trying to fix those is like playing whack-a-mole.
That's neat! Just searching for lazy I get all the relevant options, like bottom margin. I'll be tweaking those (when I page down, which I use a lot with spacebar, I go down about 1100px, so no wonder that the default of 300 isn't working for me) and only disable it altogether if this stuff still happens. Thanks!
Too late to edit but it chromium browsers it's about:flags not config
Not saying you’re wrong, or that it isn’t annoying, but in my experience it’s typically JS lazy loading solutions which cause this. Native HTML lazy loading, again in my own experience, is generally aggressive enough that I rarely if ever scroll to where an image would be in view before it loads.
so, regarding part 2: Email, call, and SMS links:
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
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
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 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).
1: https://stackoverflow.com/questions/8094835/how-to-style-htm...
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...
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!
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.
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!
poster='data:image/svg+xml,<svg …><foreignObject …><picture xmlns="http://www.w3.org/1999/xhtml">…</picture></foreignObject></svg>'
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.
> 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.
[0] Altough that's often the narrative.
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.
Good call, when you need transparency it’s a much more meaningful gain.
Heh, this is even another place where you can invoke SVG (though slightly less awful than the HTML-in-SVG-in-HTML I just mentioned, yet nonetheless pretty unnecessary nowadays): you split the alpha channel out into a separate, greyscale, image, and use it as a mask for the other image. Thus you can add a PNG or JPEG alpha channel to your JPEG. https://peterhrynkow.com/how-to-compress-a-png-like-a-jpeg/ is a good description of the technique; and JPNG.svg, at https://codepen.io/shshaw/full/LVKEdv, is one tool to generate such things.
Heh, this is even another place where you can invoke SVG (though slightly less awful than the HTML-in-SVG-in-HTML I just mentioned, yet nonetheless pretty unnecessary nowadays): you split the alpha channel out into a separate, greyscale, image, and use it as a mask for the other image. Thus you can add a PNG or JPEG alpha channel to your JPEG. https://peterhrynkow.com/how-to-compress-a-png-like-a-jpeg/ is a good description of the technique; and JPNG.svg, at https://codepen.io/shshaw/full/LVKEdv, is one tool to generate such things.
SVG are absolutely an option and I've been meaning to go that route by default for some time, but old habits die hard. I mostly use them for icons, SVG feels saner than the alternative methods and easier to work with. Combined with design work it's convenient.
Webp/png can be very useful in the sense that there is a broad understanding about how to work with plain images. A low barrier to entry, and easier collaboration in some situations.
I did not know about the alpha channel workaround. That's nice to have in the toolbox, Thanks.
Webp/png can be very useful in the sense that there is a broad understanding about how to work with plain images. A low barrier to entry, and easier collaboration in some situations.
I did not know about the alpha channel workaround. That's nice to have in the toolbox, Thanks.
Try https://tinypng.com/ for png compression.
My personal fave is Crunch[1].
1: https://github.com/chrissimpkins/Crunch
1: https://github.com/chrissimpkins/Crunch
I did a quick test, here's how it went.
Choose an example png(1) but had to redo with png(2) because tinypng.com won't chew a file larger than 5MB.
png 2.4MB ← original png
png 2.1MB ← Trimage image compressor
jpg 876.6kB ← Converseen image converter
jpg 808.2kB ← jpegcrush ← Converseen image converter
png 743.0kB ← tinypng.com (impressive!)
webp 416.3kB ← Converseen image converter
Choose an example png(1) but had to redo with png(2) because tinypng.com won't chew a file larger than 5MB.
png 2.4MB ← original png
png 2.1MB ← Trimage image compressor
jpg 876.6kB ← Converseen image converter
jpg 808.2kB ← jpegcrush ← Converseen image converter
png 743.0kB ← tinypng.com (impressive!)
webp 416.3kB ← Converseen image converter
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.
There was a "priority hints" feature that got put on hold in Chrome that let you set importance= of a resource to low/high which had this kind of use case in mind.
It amazes me that modern web frameworks don't already do this by default.
They do. Gatsby is one of them, which is why people freak out when they see that one request triggers 5mb of downloads. I think by default it only pre-loads links visible in the viewport when the page loads.
It's wasted bandwidth if the user never clicks through to the rest of the site, which is really common (think an article linked on HN).
The model a lot of devs have of the user's connection is a huge, unmetered pipe, possibly with short periods of intermittency (being on a train, etc). The web can be not such a great place if you don't match that model.
The model a lot of devs have of the user's connection is a huge, unmetered pipe, possibly with short periods of intermittency (being on a train, etc). The web can be not such a great place if you don't match that model.
I think I was expressing surprise that there isn't a mature infrastructure for this. (Thank you for introducing me to Gatsby)
You could turn it off if and when you face any bandwidth limitations - if it was a mature system, then you could turn it off globally in the browser.
Intermittency can be overcome with the right technical approach. It's potentially great for intermittent connections, since it can pre-download materials whenever your connection is good.
I guess it won't be supported between different sites, because it introduces risky conflict between tracking and privacy, that hasn't been legally resolved. (Any external link creates a privacy/tracking/security/authentication hole, whether the user clicks it or not). Maybe that's what has ultimately prevented wider adoption.
You could turn it off if and when you face any bandwidth limitations - if it was a mature system, then you could turn it off globally in the browser.
Intermittency can be overcome with the right technical approach. It's potentially great for intermittent connections, since it can pre-download materials whenever your connection is good.
I guess it won't be supported between different sites, because it introduces risky conflict between tracking and privacy, that hasn't been legally resolved. (Any external link creates a privacy/tracking/security/authentication hole, whether the user clicks it or not). Maybe that's what has ultimately prevented wider adoption.
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.
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.
Generally speaking, I said. And “very probably”. Certainly there are situations where you need to control the loading behaviour, but for typical scrolling content—a place where JS-based lazy loading has been popular—it’s not a great idea.
(And yeah, if you need lazy loading, which a large gallery probably does, then loading=lazy is unsuitable as it doesn’t guarantee anything at all, so definitely do it in JS.)
(And yeah, if you need lazy loading, which a large gallery probably does, then loading=lazy is unsuitable as it doesn’t guarantee anything at all, so definitely do it in JS.)
I mean, that's not the default webpage. If you have special use-cases ("load literally THOUSANDS OF IMAGES at once"), then of course special techniques or different approaches are on the table. I posted a comment arguing against lazy loading elsewhere in this thread, but obviously that just doesn't apply to every special scenario imaginable.
> 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.
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.
I think implicit instead of explicit labels are only an issue for Dragon NaturallySpeaking. Nuance insists Dragon is not an assistive technology and has been basically ignoring in this area. Maybe once the deal is done Microsoft will give the subject attention, they’ve been doing a lot of good for accessibility.
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.
Now there is one I can't believe I missed.
Now there is one I can't believe I missed.
I've been using it with href="#", so it simply downloads the current HTML page.
Shorter!
URLs are resolved relative to what the HTML spec calls the document base URL, and relative URL resolution of an empty string against that will yield that base URL sans fragment, just as resolving # will yield that base URL with an empty fragment.
Note also that you can’t just omit the href attribute, or else it won’t be a link.
Also note that a <base href=…> element will affect the document base URL and is thus likely to make both of these links do the wrong thing.)
<a href download>Download this page</a>
URLs are resolved relative to what the HTML spec calls the document base URL, and relative URL resolution of an empty string against that will yield that base URL sans fragment, just as resolving # will yield that base URL with an empty fragment.
Note also that you can’t just omit the href attribute, or else it won’t be a link.
Also note that a <base href=…> element will affect the document base URL and is thus likely to make both of these links do the wrong thing.)
I recently learnt about `samp`, which turned out to be ancient: https://html.com/tags/samp/
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.
Hum... Are you referring to the numbers that appear when you nest lists? As in putting an ol inside an item of another ol?
Yes. Nesting <ol> elements alone does not yield the kind of results I'm after.
You can do that with CSS alone.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Lists_a...
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Lists_a...
I'm familiar with that trick. This is the CSS solution I was referring to above. I still consider this quite 'hacky', and non-intuitive.
I actually used 5 (native search) for a fully static web (non spapp) that I helped build recently:
https://beachboyslegacy.com
https://beachboyslegacy.com
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.
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.
So much in this that I didnt know that I will refactor in my code immediately. Thank you for this post!
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.
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.
I want a cachebust="yes" attribute that invalidates an image when it changes, yet never contacts the server when the image is unchanged.
A common technique here is to use the query string to control this, with something like ?t=‹timestamp› or ?v=‹version› or ?‹hash of file contents›. Then the server can include proper cache-control headers to say “this is immutable, never going to change, don’t bother asking me if it’s changed”.
A cachebust="yes" attribute wouldn’t be useful in practice because the server would either be serving it to everyone, effectively disabling caching (and which would be better done by actually disabling caching with the cache-control header), or need to decide who to serve the attribute to, in which case there are better solutions. In short, cache busting only works if you have some sort of cache key, which is what the query string technique is all about doing.
A cachebust="yes" attribute wouldn’t be useful in practice because the server would either be serving it to everyone, effectively disabling caching (and which would be better done by actually disabling caching with the cache-control header), or need to decide who to serve the attribute to, in which case there are better solutions. In short, cache busting only works if you have some sort of cache key, which is what the query string technique is all about doing.
I've seen tools that complain about query strings for external assets. The reasons for doing so probably aren't important anymore. Instead, I include a last modified timestamp in the URL path, e.g. /files/AXkgRCa3/style.css
What I have done to accomplish this in the past is some filename shenaniganry with the file's last-modified timestamp:
<img src="/path/to/file.[last modified timestamp].png">
function auto_version($urlpath) {
// get a filesystem path
$fspath = $_SERVER['DOCUMENT_ROOT'] . $urlpath;
// if file doesn't exist, don't mess with the url
if (!file_exists($fspath)) {
return $urlpath;
}
// insert last modified timestamp
$mtime = filemtime($fspath);
return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $urlpath);
}
RewriteRule ^(.*)\.[\d]{10}\.(css|js|png)$ $1.$2 [L]
How would the browser know if the image changed?
Well, I would prefer an attribute, that is already there for some elements (like css or js files):
- Please bust cache
- Refetch and ensure, that the fetched file is securely valid
And it could be optional for every fetchable resource (img, video, css, js, etc.)
integrity="<hash>"
- Please bust cache
- Refetch and ensure, that the fetched file is securely valid
And it could be optional for every fetchable resource (img, video, css, js, etc.)
Why not just give it a new url?
It was kind of tounge-in-cheek, but giving a new url may require a redeployment which isn’t always practical
True. But I can't really think of any app that has the use case where it refreshes images in place.
Possibly an app that did that sort of thing would be some kind of gallery or other very image-centric app.
And if that were the case, then I would think the image URLs would be dynamic, not burned into the deployment.
Possibly an app that did that sort of thing would be some kind of gallery or other very image-centric app.
And if that were the case, then I would think the image URLs would be dynamic, not burned into the deployment.
Huh? That's what HEAD requests and correct HTTP headers are for, surely?
It was kind of tounge-in-cheek though
Wow, I had no clue that these existed, and I am a front-end developer!
Not to go after you in particular. But this is somehow the state of the modern web.
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.
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.
Glad you enjoyed it.
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.
I learned about webp and meter element. thank you for putting this together
TIL: start on lists, is awesome. I wonder if people think form attribute for controls, target attributes for forms (to show result in iframe), and accesskey are worthy inclusions.
great article!
just have one suggestion:
noopener is an actual security issue, the opener object is dangerous!
noreferrer is something we should do for the privacy of our users.
nofollow is for us developers to avoid our properties being connected to other properties (links are not endorsements)
maybe think about expanding that section of the docs :)
actually, rel="noopener noreferrer nofollow" should be the standard and opt-outed from. imho, rel="opener referrer follow" would have been the right thing to do.
just have one suggestion:
noopener is an actual security issue, the opener object is dangerous!
noreferrer is something we should do for the privacy of our users.
nofollow is for us developers to avoid our properties being connected to other properties (links are not endorsements)
maybe think about expanding that section of the docs :)
actually, rel="noopener noreferrer nofollow" should be the standard and opt-outed from. imho, rel="opener referrer follow" would have been the right thing to do.
I did not know about the <details> element, that's really neat. The less I can do with JavaScript, the better!
Cool, learned some new stuff. Please add the progress tag, and tips related to encoding and languages.
these are really good!
Thanks everyone for checking out my article.
If anyone is interested I also did "CSS Tips" and "JavaScript Tips" articles.
https://markodenic.com/css-tips/
https://markodenic.com/javascript-tips/
Happy coding!
https://markodenic.com/css-tips/
https://markodenic.com/javascript-tips/
Happy coding!
I wonder what else in the HTML5 spec I've missed...
Thanks for sharing this!