![]() It has nothing to do with blaming a person for a mistake, but is rather a 'show me who is responsible'. Nevertheless if I do not understand something git blame is one of the handiest tools there is. Multibyte characters like zalgo get worse. Interestingly also if you look at my tweet above in FF vs Chrome u can already see the difference in wrapping when it encounters Lao. Same for other text manipulation CSS like uppercase/word-wrap/text-overflow. If you take any sentence in Lao like ມື້ນີ້ເປັນມື້ທີ່ດີ FF & Chrome break differently. Yup it's a pretty common problem in different standards interop (CSS - W3C, JS - ECMA262, Unicode - Unicode). The important thing is, we need to learn from our mistakes, fix it swiftly, and continue moving forward □ # Community : text-overflow: ellipsis can also help in the right : white-space property has quirks around certain scripts that don’t use whitespaces so it’s not 100% i18n-safe. We need to be empathetic that we all went in with the best intention. When that happens, don't spin your wheels playing the blame game or be quick to negative judgement. During our attempt to improve things, we're going to make mistakes. In fact, it's how we progress and become better. Most of the time, we're doing bug fixes □ Quite frankly, it's why developers still have a job. We do our best but we might miss a few spots. It's very difficult to 100% understand the full extent of our implementation. But often, we won't really know until we push up the code and let our users start using it. As developers, we always try to plan for the edge cases. But before you go all git blame □, let's assume positive intent. When you're working on existing codebase, we often run into code that doesn't makes sense. That means someone actually wrote this style into our codebase □ Before you get □. That means this overlap would never had happen if we didn't implement white-space: nowrap. ![]() So I noted that white-space: normal is the default. In the mean time, if you want a head start, check out MDN docs: white-space □ # Assume Positive Intent When Working on Existing Code Base I plan to cover each of these in great details in a future code tidbit. It's important to note that in these examples, the user either:Ī) has enough context to interpret the text, even without seeing every character orī) is performing an action on the text (clicking a link) rather than interacting with it as content (reading it).įor extra clarity, you can add a title attribute to the element, so that at least on desktop, users can see the full contents when they hover with their mouse.White-space : normal /* default */ white-space : nowrap white-space : pre white-space : pre-wrap white-space : pre-line white-space : break-spaces Now, instead of text disappearing or stretching outside its boundaries on mobile or tablet, we get this: Just attach the class to whatever div or td or p you expect to have trouble adjusting to less space, and voilà! THE SOLUTION ![]() ellipsify overflow : hidden text-overflow : ellipsis white-space : nowrap It's not a one-size-fixes-all solution, but in specific situations, it's a lifesaver. One trick we've adopted to help with some of this is our ellipsify CSS class. but we still want it to not break everything (or look terrible) if an admin visits the page on her phone. At Ten Forward, we generally reserve tables for data-heavy, admin-only views, where the primary use case is desktop, not mobile. They might look good at first glance, but there's always a pesky email address or two (or 200) that stretches on for 30 characters and staunchly refuses to fit inside its designated space. When it comes to responsive design, tables are - in the words of Jean-Ralphio - "the wooooorst."
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |