Tag: Attribute

SVG Title vs. HTML Title Attribute

You know the title attribute? I can do this:

<div title="The Title">   I'm a div with a `title` </div>

And now if I’m on a device with a mouse pointer and hover the cursor over that element, I get…

Screenshot of standard text saying I'm a div with a title. A light gray tooltip is floating above the text next to the cursor that says The Title.

Which, uh, I guess is something. I sometimes use it for things like putting an expanded date or time on an element that uses shorthand for it. It’s a tiny bit of UX helpfulness reserved exclusively for sighted mouse users.

But it’s not particularly useful, as I understand it. Ire Aderinokun dug into how it’s used for the <abbr> element (a commonly cited example) and found that it’s not-so-great alone. She suggests a JavaScript-enhanced pattern. She also mentions that JAWS has a setting for announcing titles in there, so that’s interesting (although it sounds like it’s off by default).

I honestly just don’t know how useful title is for screen readers, but it’s certainly going to be nuanced.

I did just learn something about titles though… this doesn’t work:

<!-- Incorrect usage --> <svg title="Checkout"> </svg>

If you hover over that element, you won’t get a title display. You have to do it like this:

<!-- Correct usage --> <svg>   <title>Checkout</title>      <!-- More detail -->   <desc>A shopping cart icon with baguettes and broccoli in the cart.</desc> </svg>

Which, interestingly, Firefox 79 just started supporting.

When you use title like that, the hoverable area to reveal the title popup is the entire rectangle of the <svg>.

I was looking at all this because I got an interesting email from someone who was in a situation where the title popup only seemed to come up when hovering over the “filled in” pixels of an SVG, and not where transparent pixels were. Weird, I thought. I couldn’t replicate in my testing either.

Turns out there is a situation like this. You can apply a <title> within a <use> element, then the title only applies to those pixels that come in via the <use>.

If you remove the “white part” title, you’ll see the “black part” only comes up over the black pixels. Seems to be consistent across browsers. Just something to watch out for if that’s how you apply titles.

The post SVG Title vs. HTML Title Attribute appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

Responsive Styling Using Attribute Selectors

One of the challenges we face when implementing class-based atomic styling is that it often depends on a specific breakpoint for context.

<div class="span-12"></div> <!-- we want this for small screens  --> <div class="span-6"></div>  <!-- we want this for medium screens --> <div class="span-4"></div>  <!-- we want this for large screens  -->

It’s common to use a prefix to target each breakpoint:

<div class="sm-span-12 md-span-6 lg-span-4"></div>

This works well until we start adding multiple classes. That’s when it becomes difficult to keep a track what relates to what and where to add, remove. or change stuff.

<div class="   sm-span-12    md-span-6    lg-span-4    sm-font-size-xl    md-font-size-xl    lg-font-size-xl    md-font-weight-500    lg-font-weight-700"> </div>

We can try to make it more readable by re-grouping:

<div class="   sm-span-12    sm-font-size-xl  
   md-span-6    md-font-size-xl    md-font-weight-500  
   lg-span-4    lg-font-size-xl    lg-font-weight-700"> </div>

We can add funky separators (invalid class names will be ignored):

<div class="   [    sm-span-12     sm-font-size-xl    ],[    md-span-6     md-font-size-xl     md-font-weight-500    ],[    lg-span-4     lg-font-size-xl     lg-font-weight-700   ]"> </div>

But this still feels messy and hard to grasp, at least to me.

We can get a better overview and avoid implementation prefixes by grouping attribute selectors instead of actual classes:

<div    sm="span-12 font-size-lg"   md="span-6 font-size-xl font-weight-500"   lg="span-4 font-size-xl font-weight-700" > </div>

These aren’t lost of classes but a whitespace-separated list of attributes we can select using [attribute~="value"], where ~= requires the exact word to be found in the attribute value in order to match.

@media (min-width: 0) {  [sm~="span-1"] { /*...*/ }                [sm~="span-2"] { /*...*/ }     /* etc. */  } @media (min-width: 30rem) {  [md~="span-1"] { /*...*/ }     [md~="span-2"] { /*...*/ }     /* etc. */    } @media (min-width: 60rem) {  [lg~="span-1"] { /*...*/ }     [lg~="span-2"] { /*...*/ }     /* etc. */    }

It may be a bit odd-looking but I think translating atomic classes to  attributes is fairly straightforward (e.g. .sm-span-1 becomes [sm~="span-1"]). Plus, attribute selectors have the same specificity as classes, so we lose nothing there. And, unlike classes, attributes can be written without escaping special characters, like /+.:?.

That’s all! Again, this is merely an idea that aims to make switching declarations in media queries easier to write, read and manage. It’s definitely not a proposal to do away with classes or anything like that.

The post Responsive Styling Using Attribute Selectors appeared first on CSS-Tricks.


, , , ,

Using the HTML title attribute

 Steve Faulkner:

User groups not well served by use of the title attribute

• Mobile phone users.
• Keyboard only users.
• Screen magnifier users.
• Screen reader users.
• Users with fine motor skill impairments.
• Users with cognitive impairments.

Sounds like in 2020, the only useful thing the title attribute can do is label an <iframe title="Contact Form"></iframe>.

Direct Link to ArticlePermalink

The post Using the HTML title attribute appeared first on CSS-Tricks.


, , ,

Select an Element with a Non-Empty Attribute

Short answer:

[data-foo]:not([data-foo=""] {

Longer answer (same conclusion, just an explanation on why we might need this):

Say you have an element that you style with a special data-attribute:

<div data-highlight="product"> </div>

You want to target that element and do special things when highlighting.

[data-highlight] {   font-size: 125%;  }  [data-highlight="product"] img {   order: 1; }

That data-type attribute is part of a template, so it can have any value you set.

<div data-highlight="{{ value }}"> </div>

And sometimes there is no value! So the output HTML is:

<div data-highlight=""> </div>

But this can be tricky. See in that first CSS block above, we’re wanting to target all elements with the data-highlight attribute, buttttt, we actually only wanna do it if it has a value. If the value is blank, we want to just skip any special styling at all.

In a perfect world, we’d just remove the data-attribute from the HTML template when there is no value. But a lot of templating languages, on purpose, don’t allow logic in them that would help us put-or-not-put that attribute entirely.

Instead, we can solve it with CSS:

[data-highlight]:not([data-highlight=""] {   font-size: 125%;  }  [data-highlight="product"] img {   order: 1; }

The post Select an Element with a Non-Empty Attribute appeared first on CSS-Tricks.


, , ,

The `hidden` Attribute is Visibly Weak

There is an HTML attribute that does exactly what you think it should do:

<div>I'm visible</div> <div hidden>I'm hidden</div>

It even has great browser support. Is it useful? Uhm. Maybe. Not really.

Adam Laki likes the semantics of it:

If we use the hidden attribute, we make our semantic a little better. Anybody will understand what does a “hidden” attribute means on an element.

Monica Dinculescu calls it a lie:

the hidden rule is a User Agent style, which means it’s less specific than a moderate sneeze. This means that your favourite display style will override it:

<style>   div { display: block; } </style> <div hidden>   lol guess who's not hidden anymore   hint: it's this thing </div>

So two related problems…

  1. It’s extremely weak. Literally any change to the display property other than the none value on the element with any strength selector will override it. Much like any other display property, like width or whatever, except the it feels somehow worse to have a hidden attribute actively on an element and have it not actually be hidden.
  2. The display property is sadly overloaded with responsibility. It would be way cool if hidden was a CSS property that could be in charge of the visibility/access of elements rather than the same property that controls the type of block it is. But alas, backward compatibility 4-lyfe of the web stops that (which is a good thing for the health of the web overall).

If you really love the semantics of the attribute, Monica suggests:

[hidden] { display: none !important; }

Seems like a nice addition to any “reset” or base stylesheet.

Otherwise, the classic technique of hiding things with a class is absolutely fine. I typically have a utility class:

.hide, .hidden {   display: none; }

But remember there are always a million ways to do things. I find myself regularly doing one-off hide/show mechanisms. For example, a menu that you need to toggle the visibility of with flair, but remain accessible at all times…

.menu {    opacity: 0;    visibility: hidden;    transition: 0.2s;    transform: translateX(20px);    &[data-open] {      opacity: 1;      visibility: visible;      transform: translateX(0);    } }

The post The `hidden` Attribute is Visibly Weak appeared first on CSS-Tricks.


, , ,