![]() ![]() ![]() Showing text-overflow with a width-constrained list in a 640px viewport So it’s used in combination with other properties that restrict and clip the boundaries of a container, typically width or max-width combined with overflow: hidden.Īnd here’s an example of what that can look like when it takes effect: The text-overflow property itself does not truncate text, it only specifies how the truncation should be indicated when it does occur. ![]() ![]() If text has been truncated with text-overflow, then this is a loss of content, and therefore an instant failure of 1.4.10.Īlthough the article concedes the possibility of valid use cases, I would personally go a step further and say there are none - that text-overflow should never be used. Horizontal scrolling content at a height equivalent to 256 CSS pixels.Įxcept for parts of the content which require two-dimensional layout for usage or meaning.Vertical scrolling content at a width equivalent to 320 CSS pixels.So I was very pleased to see someone else flying the same flag.Ī recent article by Eric Eggert is quite critical of this property, since using it in web content can cause it to fail Success Criterion 1.4.10 Reflow:Ĭontent can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: I’m not a fan, and take every suitable opportunity to discourage people from using this property though I rarely get enthusiastic support on that point. The CSS text-overflow property can be used to show a visual indication for text that’s been clipped by its container. Here is the CSS I’ve written for the above example. I’ll go straight to the code and would explain some parts of it later. With fallback to just text-overflow: ellipsis when there is no support for flex-wrap. Ah, and also whenever you see the shorter line, the longer part would be also accessible as an HTML title. The code beyond this example is just some HTML & CSS which uses flexbox, and is made to be accessible to screen-readers which would read only the longest part, ignoring the shorter one. Some long text that could become shorter. That’s what you could see happening in the gif at the start of this article, and here is a much simpler live example (try to resize the wrapper or toggle the toggler to see how it would behave): But very often we don’t want to just truncate our long text strings: we could want to substitute it with some other text instead, remove some parts, or replace it with just an icon. Whenever we have a very long string that won’t fit our available space, the most obvious solution is text-overflow: ellipsis. Today I’ll present you with one of those cases. But their future is not certain, and while there are polyfills that allow us to use some of their possible features, the need to polyfill everything can be daunting.īut should we rely on JS or look at our news feeds in anticipation of Container Queries all the time? What if CSS is already powerful enough to solve some of the potential Container Queries use cases right now? What if CSS could even solve some of the responsive cases that even Container Queries probably couldn’t solve ? Very often we don’t know the dimensions we could rely on, even on per-component basis, so queries not always could help us, and we need to learn how to use more complex CSS to achieve what we want. One of the solutions everyone is waiting for is Container Queries (formerly known as Element Queries). Our components need to be independent and work in any conditions. Today, in the era of components, we can’t rely just on the width of our viewport anymore. A lot of people love responsive sites, and we used to make them with the help of Media Queries. ![]()
0 Comments
Leave a Reply. |