Ask HN: Why do I see so much crazy inline styling on websites these days?

16 points by TicklishTiger ↗ HN
I just googled for 'cloud hosting' and landed here:

https://try.digitalocean.com/cloud-hosting/

I'm often curious how the source of a page looks like. So I inspected the headline "Cloud hosting developers love.".

This is what I found:

<h1 style="line-height: 77px;"> <span style="font-size: 60px; letter-spacing: -1.33px;"><span style="color: rgb(255, 255, 255);"><span class="ub-dynamic">Cloud</span></span></span><span style="font-size: 72px; letter-spacing: -1.33px;"><span style="color: rgb(255, 255, 255);">&nbsp;</span></span><span style="font-size: 60px; letter-spacing: -1.33px;"><span style="color: rgb(255, 255, 255);">hosting</span></span> <br> <span style="font-size: 60px; letter-spacing: -1.33px;"><span style="color: rgb(255, 255, 255);">developers love.&nbsp;</span></span> </h1>

I find this kind of crazy inline styling and absurd choice of elements pretty often these days. Why? What is going on?

12 comments

[ 4.2 ms ] story [ 35.7 ms ] thread
Most likely the product of server-side automated styling.
From a WYSIWIG editor or the result of manual PSD2HTML conversion.
Might be for use on web and email advertisements where inline styling is a necessity.
Seems like it was generated by some kind of a WYSIWYG editor or maybe it's just another simple obfuscating tool designed for simple scrappers.
That particular page appears to have been created with "Unbounce" (https://preview.unbounce.com/) (the "lp-*" strings give that away). If you look for said "lp-" strings on the web there are more than a few pages using them. Unbounce is primarily designed for creating HTML email that won't break and won't get auto-rejected and it's likely easier for the builder program to stick in hardcoded values in-tag than to rely on complex CSS, especially with the varied capabilities of mail clients.
Yep. Unbounce is very much an old school WYIWYG editor in web app form, and its code basically reflects that. Everything built with it is done with absolute positioning and hard coded values (presumably because, as said, it's likely easier for the devs to generate it like that than relying on complex CSS rules).
It is a good practice for static pages focused on performance (e.g. landing pages like this one) that the critical CSS is inline. It is common that all CSS for above the folder content is inline - usually done through a processor, so the development code is kept sane.

A kind of old, but relevant source: https://developers.google.com/speed/pagespeed/service/Priori...

Inlining of "critical" css is favoured for page load speed, but not like that...
It looks generated but not minified. If performance were a concern, they'd minify it, i.e., strip out unnecessary whitespace, punctuation and rename ids/classes to some Huffman-encoded obsfucated replacements to make it look vaguely like Google's homepage
> crazy inline styling and absurd choice of elements pretty often these days

i'd be interested to hear what objectively measurable properties this way of doing things might suffer from. e.g.

  1. does it result in more data being sent over the wire?
  2. does it result in slower page load speed?
  3. is it less widely supported by browsers?
  4. is it harder to maintain?
It's a bit hard to assess if this is easy to maintain without knowing how the page is generated. Maybe it's built by some pipeline that is very easy for the developers to maintain & easy for people to tweak the styles...

(context: genuine interest, backend dev who has largely dodged having to care about html for the last n years...)

Also, many React libraries automatically inline styles when server-side rendered, to (as mentioned by other commenters) improve page performance. The developers working on the page most likely didn't write the style directly inline, but was added in compilation, through a library, or using React's style prop.