Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defensive CSS

defensivecss.dev

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Defensive CSS

#61

Post by chrismorgan »

wnevets wrote: post #37
Dan42 wrote: post #26

Ok, the first thing I looked at is "long content" https://defensivecss.dev/tip/long-content/ and here they recommend to just clip it. Because who cares about content right? Who cares if the partial content you display is useless, as long as it looks good. And that's the kind of tip everyone here is applauding. I would like to say webdesign is in a sorry state nowawadays, except it was also that way 20 years ago. Mayb…

What a odd one to single out and complain about it.

Seems very reasonable to me. The advice is very dubious, but presented as absolute truth with no nuance. That’s bad, and, applying it more generally, if there’s one thing from the first row of tips that’s bad, it’s unlikely to be the only one.

This sort of thing reduces confidence. I can also say from looking through a number of others that they often lack nuance, and present a solution to a possible problem, without contemplating why that problem arose, and whether the solution is actually the right solution. (e.g. image distortion and background repeat are both a bit weird when you think about them, and the solutions offered are blunt and often not very good with no suggestion on how they could be improved. And flexbox wrapping basically assumes that horizontal scrolling is bad and needs to be fixed, which it isn’t always, but somehow also misattributes the scrolling in the diagram, making it seem as though it’s the flex container that’s scrolling, when in fact it’s just overflowing and causing its parent scroll area, probably the document scroll area, to have a scrollbar, and that is more likely to be problematic if not managed deliberately; but it also completely neglects to mention the more likely problem with flex overflow, which is your items not triggering overflow, but instead being squished narrower than intended, and that is the thing that would actually be worth while describing the solution for—flex-basis and flex-shrink.)

Re: Defensive CSS

#62

Post by totetsu »

webstrand wrote: post #43
rmbyrro wrote: post #40

Earlier quoted context omitted.

Clipping shouldn't be done at the design level. This is an application logic concern. If the application did not impose a character limit, or imposed a large one, the design must accommodate this freedom.

But what about user-agents that override font-face and font-size? Those are important accessibility features for people with poor vision or dyslexia. Without knowing the rendered width of the text string, you can't limit the text ahead of time. Or are you saying that all designs that can't accommodate text-wrapping should be avoided?

Or using a page translation service.

Re: Defensive CSS

#63

Post by chrismorgan »

rmbyrro wrote: post #40
webstrand wrote: post #38

Earlier quoted context omitted.

But that's only one of the tips, the rest of the tips are about adapting to arbitrary screen size and content without visually breaking? Sometimes you just have to clip user-generated content, though, because you can't tell the user to "make sure the label succinct enough to fit in this menu." The user will do as they please, and the layout must adapt or break. What alternative is there? Sure, you could limit the len…

Clipping shouldn't be done at the design level. This is an application logic concern. If the application did not impose a character limit, or imposed a large one, the design must accommodate this freedom.

One uncommon place where clipping is justified at the design level: lazy-loading of finite but known-size lists, with a real and correct scrollbar. I’ll use Fastmail’s webmail (on which I worked a few years back) as an example. I could load a list of a hundred thousand emails, and each message in the list is, under my configuration, 88px tall (containing four lines of text—approximately, sender and date, subject, and two lines of preview, with truncation on each), so the list container is made to be 8,800,000 pixels high¹, and I can use its scrollbar to immediately jump to any place, and it will figure out which messages to fetch and render based on the scroll position.

If the subject line were wrapped, which would be nice at times, you’d lose this ability: you’d have to guess the approximate height of each element, and your scroll positions will be imprecise and you’ll have to make messy adjustments from time to time. Overall it generally won’t be too bad so long as there’s not too much variation in them, but it’s definitely still inferior.

You can then read the full subject line and other truncated fields either by opening the email, or by hovering, as the full text is set as the tooltip. And here’s a general tip for others: if you do ever automatically truncate overflowing text, you should set the element’s tooltip to the full text.

—⁂—

¹ Browser do have limits on how large you can make containers, and handle excess in different ways. IE had the lowest threshold of failure at around ten million pixels, beyond which point it would ignore values; the workaround I implemented in https://github.com/fastmail/overture/commit/8d01c74d8c5d4ae0... came as a direct result of a customer reporting that scrolling was broken in IE in their mailbox with a couple of hundred thousand emails. Firefox breaks a little after 2²⁴ pixels, also ignoring values, so it’s still covered in https://github.com/fastmail/overture/blob/0c9828a5b77ad14383... (note the IE stuff is gone because IE is dead! :-) ). WebKit-heritage browsers accept larger values, but clamp them to about 2²⁵ pixels. In all cases, the clamping solution means you can’t access the emails at the end of the list. C’est la vie.

Re: Defensive CSS

#64

Post by WA »

rmbyrro wrote: post #40
webstrand wrote: post #38

Earlier quoted context omitted.

But that's only one of the tips, the rest of the tips are about adapting to arbitrary screen size and content without visually breaking? Sometimes you just have to clip user-generated content, though, because you can't tell the user to "make sure the label succinct enough to fit in this menu." The user will do as they please, and the layout must adapt or break. What alternative is there? Sure, you could limit the len…

Clipping shouldn't be done at the design level. This is an application logic concern. If the application did not impose a character limit, or imposed a large one, the design must accommodate this freedom.

A data point may be used in several places in your UI. Why should it be clipped at the application level, if the same string is shown in a headline or list abbreviated and in another place in full?

Re: Defensive CSS

#65

Post by mixmastamyk »

danielheath wrote: post #50
jakearmitage wrote: post #22

Earlier quoted context omitted.

The real crazy thing is that Delphi/VB got UIs right in the 90s and the JS folks keep reinventing everything.

I loved that era and it was great, but it didn’t handle resizing to fit different screen sizes well at all. I’m still holding out for a similar interface builder that can handle responsive design.

Layout managers handle window resizing, which heavily overlap. Started using them in the 90s.

Re: Defensive CSS

#66

Post by rimliu »

distantsounds wrote: post #28
eurasiantiger wrote: post #21

Earlier quoted context omitted.

That’s not what the site is about at all. It’s ”defensive” in the same sense as ”defensive programming”: handling possible future / edge cases gracefully.

the fact you can set a CSS version in your code, and have it not act as it did when that version was originally standardized, is exactly what being "defensive" is about. the code you wrote years ago doesn't work anymore because the browsers have decided to do things differently now. and yet I can run applications from 30 years ago and it will still function as it once did. no hacks or code changes required. you shoul…

Windows is full of hacks to allow that "I can run applications from 30 years ago" to happen.

Re: Defensive CSS

#67

Post by account42 »

webstrand wrote: post #51
danielheath wrote: post #48

Earlier quoted context omitted.

If the user has large text because they can’t read easily, how is clipping it short going to help them read it?

Usually when the layout breaks, functionality is lost: buttons can't be clicked on, text can't be read, content is obscured to the right, etc. If none of these things are happening, I'd agree not clipping is fine.

Do you have any data to back up that "usually"? IME more often than not the only reason why content is clipped is because of looks not because of functionality. This also applies to the example in the article.

The HTML default is to flow elements to make space for larger conent. You need to go out of your way to break that.

Re: Defensive CSS

#68

Post by account42 »

8n4vidtmkvmk wrote: post #60
BiosElement wrote: post #4

Really love the togglable examples. It's often hard to imagine how a change look and while in a perfect world I'd have time to make a mockup to test each version, well, it's hardly a perfect world so examples are appreciated!

the examples are certainly nice but it only takes a second to resize your browser when testing your own site

You don't even need to resize the whole browser window - you can use the responsive design mode of your browser's development tools to resize just the viewport of the website you are working on. And it can even emulate touch interfaces to test the relevant media queries.

And resizing the window is also something native application developers should embrace. Always roll my eyes when some game developer says they can only target 16:9 because they don't have other monitors - just make your window mode resizable and drag the corner.

Re: Defensive CSS

#69

Post by noisymemories »

squidbeak wrote: post #53
distantsounds wrote: post #28

Earlier quoted context omitted.

the fact you can set a CSS version in your code, and have it not act as it did when that version was originally standardized, is exactly what being "defensive" is about. the code you wrote years ago doesn't work anymore because the browsers have decided to do things differently now. and yet I can run applications from 30 years ago and it will still function as it once did. no hacks or code changes required. you shoul…

I'm curious which css code from years ago won't work any more. Care to elaborate?

Not OP, but flexbox went very famously trough a few breaking changes throughout its early history: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexibl...

There were also some more subtle behavior changes a few years ago in the way webkit handled unprefixed flex-direction centering properties (align-items, justify-content) together with min-width/min-height attributes, switching from behaving closer to IE11 in this regard to basically emulating Blink. AFAIK neither behavior was really against-spec.

And if you really want to go all-in with some really deep philosophical questions, I can suggest you the following: Is it possible to center text in a select box? https://stackoverflow.com/questions/10813528/is-it-possible-...

Re: Defensive CSS

#70

Post by isleyaardvark »

wnevets wrote: post #37
Dan42 wrote: post #26

Ok, the first thing I looked at is "long content" https://defensivecss.dev/tip/long-content/ and here they recommend to just clip it. Because who cares about content right? Who cares if the partial content you display is useless, as long as it looks good. And that's the kind of tip everyone here is applauding. I would like to say webdesign is in a sorry state nowawadays, except it was also that way 20 years ago. Mayb…

What a odd one to single out and complain about it.

"Not making content inaccessible" is one of most fundamental principles of front-end work. The famous "CSS is awesome" coffee mug shows the correct default when something is not working like expected: the content is still visible. Defensive CSS should be intended to fail gracefully, and clipping it doesn't do that. (i.e. when it breaks it'll look bad but the content should still be available.)

I read this bit and I feel like I'm taking crazy pills:

>In some scenarios, we might need to truncate a text that isn't important for the user, or doesn't affect the user experience.

If that's the case, then what is the text even for?

This is a text based medium, the text is the content, it's the reason the user is here, they're not here to admire the consistent vertical layout. The priorities are entirely backwards.

Post reply on HN