[HN Gopher] HTML Tips (2020)
___________________________________________________________________
HTML Tips (2020)
Author : web_master
Score : 236 points
Date : 2021-05-05 19:14 UTC (3 hours ago)
(HTM) web link (markodenic.com)
(TXT) w3m dump (markodenic.com)
| didymospl wrote:
| 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.
| rchaud wrote:
| 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
| rayrag wrote:
| 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/
| lucb1e wrote:
| 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)?
| tylerscott wrote:
| TIL about <meter> and wow is it interesting. Here is the spec:
| https://www.w3.org/TR/html52/sec-forms.html#the-meter-elemen...
|
| I wonder what else in the HTML5 spec I've missed...
|
| Thanks for sharing this!
| mdenic wrote:
| Glad you enjoyed it.
| webflow wrote:
| Interesting that most post for this url come from accounts
| created the day it was posted.
|
| Post on your own account you coward.
|
| Also I get the irony that this account was just created.
| theandrewbailey wrote:
| > 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.
| jnellis wrote:
| Is that only an artifact of dynamically updating them? Firefox
| and chrome do as expected in the example; match any substring.
| asddubs wrote:
| on firefox it finds all phrases containing the entered string
| intergalplan wrote:
| 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.
| theandrewbailey wrote:
| > Form validation should be built-in
|
| Have you used pattern attributes?
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Attributes...
| edoceo wrote:
| and the :invalid css option (I like to just make the bottom
| border red, dashed)
| asddubs wrote:
| drag and drop rearrangeable lists as a form element!
| intergalplan wrote:
| 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.
| open-source-ux wrote:
| 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-...
| tyingq wrote:
| Didn't know about <ol start="<number>">
|
| Now I can have proper zero indexed lists and annoy friends.
| Chrome even supports negative integers.
| wanda wrote:
| 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 (the joys of developing
| for the web) and obviously 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...
| Pabblo001 wrote:
| Thanks! Nice blog btw.
| mdenic wrote:
| Thanks! Glad you liked it.
| chrismorgan wrote:
| 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. 1 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. 2 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 x
| mlns="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.
| Jiocus wrote:
| > 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.
| chrismorgan wrote:
| 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.
| Jiocus wrote:
| 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.
| slver wrote:
| 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.
| lucb1e wrote:
| 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.
| chrismorgan wrote:
| _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.)
| c22 wrote:
| 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.
| zamadatix wrote:
| 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.
| teachingassist wrote:
| It amazes me that modern web frameworks don't already do this
| _by default_.
| eyelidlessness wrote:
| > 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.
| zamadatix wrote:
| 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.
| AdmiralAsshat wrote:
| 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.
| poniko wrote:
| Oh yes it does, you need to specify width and height for it to
| work properly.
| dynm wrote:
| 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.
| austincheney wrote:
| If you know the size of the incoming image specify its
| dimensions with CSS.
| ilkka_es wrote:
| Wow, I had no clue that these existed, and I am a front-end
| developer!
| mdenic wrote:
| Glad you enjoyed it.
| lucb1e wrote:
| #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?
| eyelidlessness wrote:
| 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.
| zamadatix wrote:
| 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.
| lucb1e wrote:
| 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!
| eyelidlessness wrote:
| 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.
| yummybear wrote:
| I want a cachebust="yes" attribute that invalidates an image when
| it changes, yet never contacts the server when the image is
| unchanged.
| abraae wrote:
| Why not just give it a new url?
| yummybear wrote:
| It was kind of tounge-in-cheek, but giving a new url may
| require a redeployment which isn't always practical
| intergalplan wrote:
| Huh? That's what HEAD requests and correct HTTP headers are
| for, surely?
| yummybear wrote:
| It was kind of tounge-in-cheek though
| chrismorgan wrote:
| 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.
| theandrewbailey wrote:
| 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
| jkaptur wrote:
| How would the browser know if the image changed?
___________________________________________________________________
(page generated 2021-05-05 23:00 UTC)