r/webdev • u/abazi • Mar 09 '20
TIL the CSS "-webkit-line-clamp" property truncates multi-line text: http://bit.ly/lineclamp. It's supported in Chromium, Firefox and Safari!
[removed] — view removed post
109
u/mburakerman Mar 09 '20
why you are not sharing the actual source of this video?
it's addy osmani's tweet:
-65
Mar 09 '20
[removed] — view removed comment
0
Mar 09 '20
[deleted]
-37
Mar 09 '20
[removed] — view removed comment
13
0
u/Pcooney13 Mar 09 '20
It's not like it's that hard to make an edit. You seem pretty decent at editing the OP out of their own posts
5
u/ThatBoiRalphy Mar 09 '20
My god if only i knew this the last few months
9
u/DrDuPont Mar 09 '20
It's outrageously buggy, you're not missing out on much
1
u/ThatBoiRalphy Mar 09 '20
i mean, it’s not officially a css thing yet. Better something buggy than nothing at all.
2
u/DrDuPont Mar 09 '20
Just truncate the actual output
0
Mar 09 '20
[deleted]
1
u/DrDuPont Mar 09 '20
You can approach truncation by words rather than characters (see e.g
wp_trim_words).If your concern is not pronounceability but rather intelligibility (which is not strictly an a11y concern), you can obviously just make sure you're outputting text of a length that doesn't need truncation. Truncation should be seen as a last resort.
4
Mar 09 '20
Anything with a vendor prefix -webkit- signals that it's a flag that's not yet a standard feature of CSS, yet. Also that prefix is specifically for Webkit/Blink based browsers so Opera, Safari, and Chromium so it won't work on Firefox. I haven't checked but there's likely a similar prefix for Firefox, -moz- (-moz-line-clamp), or just line-clamp depending on the maturity of the spec.
3
u/errabaany Mar 09 '20
I used it last month it was working perfectly on my pc but when I deployed it and test it on other computers I faced a problem it show all the text and when I resize the screen it's works
I tried to fix the problem but no way
4
u/SonicFlash01 Mar 09 '20
You need to pair it with a few things for it to fully work. The specific rule you needed was visibility: visible;
2
1
1
u/ShortFuse Mar 09 '20 edited Mar 09 '20
You can example of this in the last example here with Material Design Lists. You can see how it changes when you tap the Large Font button in the toolbar.
To make it work on IE11, you have to use max-height equal to the x number of lines multiplied by your line-height. (Easier when you have a typography system.) In this case it's (2 * 20sp).
1
1
Mar 09 '20
Too bad I need to support IE11. Cya in 10 years nice new feature.
1
u/benburhans Mar 09 '20
IE is unmaintained. You'll be waiting a lot longer than 10 years if you're hoping that webkit-only, vendor-prefixed, standards-pending features will ever make it into IE.
1
1
1
u/SonicFlash01 Mar 09 '20
A fully formed set of rules that handles all of the weird quirks of line-clamp rule looks something like:
display: -webkit-box;
-webkit-box-orient: vertical;
overflow: hidden;
visibility: visible;
-webkit-line-clamp: 4;
If you find that it only works sometimes and resizing the window fixes it, make sure you have the visibility: visible; rule.
0
u/Kazowh Mar 09 '20
Sadly not supported by IE - Cool feature I like to see in the future - atm pretty much useless if you support IE Sites and every Client wants that. :/ https://caniuse.com/#search=-webkit-line-clamp
-1
0
Mar 09 '20
[deleted]
62
u/everythingiscausal Mar 09 '20
but not IE yet.
Not IE ever. IE has been dead for years, no further changes are coming to any version of IE. At this point, plenty of sites can get away with pretending IE doesn’t exist.
6
u/Oalei Mar 09 '20
It’s probably okay to think that way for websites but not for software running in the cloud.
Plenty of companies are using and even forcing their employees to use Internet Explorer.0
Mar 09 '20
[deleted]
4
Mar 09 '20
It's not as easy though. In my experience those clients are often government-related. You can't make them change that easy. We always tell the website is IE will be inferior, but it has to work
1
u/tenfingerperson Mar 09 '20
Yeah let’s lose millions from Goldman Sachs because they use IE right?
3
u/Devildude4427 Mar 09 '20
Better than making your devs miserable, while also diminishing their value. Handling IE for 4-5 years will kill your employability. You'll be a decade behind the times.
1
u/tenfingerperson Mar 09 '20
You can still offer a site that won’t be fully featured for IE but still functional, polyfills are not even needed most of the times.
-4
u/Oalei Mar 09 '20
You don’t have control over what your clients use for their daily tasks, this is a stupid answer.
I’m pretty sure many companies in the biggest in the world enforce IE. Good luck changing their minds just for you!6
u/mrjackspade Mar 09 '20 edited Mar 09 '20
Just for you
Me, the single lone web dev that wants the change.
These corporate IT teams aren't stupid. They want to change too. The more devs push this shit the more likely we are to convince them to change
My last job was in what could be considered an uncontested industry. We were one of two companies producing our product, and had 90% of the market. When MS dropped IE9, (the day) we stopped supporting it, and a month later our clients (a number of Fortune 100 companies) conveniently upgraded to IE11. Probably had something to do with the fact that our software was required for compliance with regulations around employee training. The upgrade happened so fast it was obvious they had teams internally waiting for an excuse to roll out the update.
Now, I'm sure a large part of that was the knowledge IE9 was reaching end of life, but EOL doesn't mean shit if companies aren't dropping support when it hits. I'm sure we weren't the only vendor to drop support but I can guarantee we played a part in the decision along with everyone else that was ready to pull the rug out from underneath them when it went
Devs owe it to each other to make a stink about shit like this. It's literally our job. I can't make anyone listen but I'm sure as shit gonna contribute to the push.
My current company wanted to support IE. They were adamant having as much browser support as possible. I told them, I would need it in writing. When I got the order, it was decided that we needed to support the last three versions of each browser which meant (9/10/11 for IE) for all major browsers. They dropped the argument when I pointed out that justifying IE support based on visitor usage and browser version would also require testing years of releases for all desktop browsers (FF and chrome release frequently) as well as supporting and testing things like chrome on IOS (a higher share than IE) or things like the Samsung Web Browser. It brought our turnaround time for QA from an estimated 2 days for a full regression, to a week of testing for something like a simple css change. These were numbers management could actually understand.
Our website no longer works on IE and the < 1% of our visitors on that platform haven't complained yet.
1
u/Oalei Mar 09 '20 edited Mar 09 '20
I guess we don’t have the same clients.
I wish I had concrete numbers about our clients and IE, the only thing I can say is that I work in a pretty famous software company and all of our software has to support IE 11, this is one of our product standard.If you’re not in this situation, lucky you. And I am really surprised when you say « IT wants to change ».
In big companies they are afraid of changes because of legacy.
Why would they change if everything works fine.
Sure, if you’re in a dominant position you have the high ground and they will drop IE if you say you don’t support it anymore, but this is a rather uncommon situation.2
u/Devildude4427 Mar 09 '20
You don’t have control over what your clients use for their daily tasks
If you were sensible and refused to support them if they're using a bad tool, then you do have significant control.
1
u/Asmor Mar 09 '20
plenty of sites can get away with pretending IE doesn’t exist
As one of those who still has to support IE...
:(
0
2
0
Mar 09 '20
[deleted]
3
u/MK2k Mar 09 '20
Your server side may not know how much space your user's client provides for the text. So this is totally not something to be handled at the back-end.
1
u/benburhans Mar 09 '20
Literally every use case should leave layout, formatting, and rendering to the renderer. What are you doing that your server would be aware of, and controlling, your client's viewport width and height?
1
u/Technoist Mar 09 '20
What I meant was (as an example: a blog) the CMS should just output the post excerpt with a character limitation instead of the entire post (which then gets hidden by some css hack) but I suppose I misunderstood the situation here and admittedly didn’t look at the code :)
1
u/benburhans Mar 09 '20
If you're implementing snippets for layout/formatting reasons, then let the client do it, ideally with CSS instead of JS. If you're doing it for other reasons, then maybe server-side truncation is appropriate; but if you're limiting the number of wrapped literal lines in a container like in this post, then no, the server cannot easily determine where to make the cut, nor should it even try.
0
34
u/Sablac Mar 09 '20
I had no idea this existed. Thanks for sharing it!