Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
149648 stories
·
33 followers

On Inheriting and Sharing Property Values

1 Share

Sometimes I want to set the value of a CSS property to that of a different property, even if I don’t know what that value is, and even if it changes later. Unfortunately though, that’s not possible (at least, there isn’t a CSS function that specifically does that).

In my opinion, it’d be super useful to have something like this (for interpolation, maybe you’d throw calc-size() in there as well):

/* Totally hypothetical */
button {
  border-radius: compute(height, self);
  border-radius: compute(height, inherit);
  border-radius: compute(height, #this);
}

In 2021, Lea Verou explained why, despite being proposed numerous times, implementing such a general-purpose CSS function like this isn’t feasible. Having said that, I do remain hopeful, because things are always evolving and the CSSWG process isn’t always linear.

In the meantime, even though there isn’t a CSS function that enables us to get the value of a different property, you might be able to achieve your outcome using a different method, and those methods are what we’re going to look at today.

The fool-proof CSS custom properties method

We can easily get the value of a different CSS property using custom properties, but we’d need to know what the value is in order to declare the custom property to begin with. This isn’t ideal, but it does enable us to achieve some outcomes.

Let’s jump back to the example from the intro where we try to set the border-radius based on the height, only this time we know what the height is and we store it as a CSS custom property for reusability, and so we’re able to achieve our outcome:

button {
  --button-height: 3rem;
  height: var(--button-height);
  border-radius: calc(var(--button-height) * 0.3);
}

We can even place that --button-height custom property higher up in the CSS cascade to make it available to more containment contexts.

:root {
  /* Declare here to use anywhere */
  --button-height: 3rem;

  header {
    --header-padding: 1rem;
    padding: var(--header-padding);
  
    /* Height is unknown (but we can calculate it) */
    --header-height: calc(var(--button-height) + (var(--header-padding) * 2));
  
    /* Which means we can calculate this, too */
    border-radius: calc(var(--header-height) * 0.3);
  
    button {
      /* As well as these, of course */
      height: var(--button-height);
      border-radius: calc(var(--button-height) * 0.3);

      /* Oh, what the heck */
      padding-inline: calc(var(--button-height) * 0.5);
    }
  }
}

I guess when my math teacher said that I’d need algebra one day. She wasn’t lying!

The unsupported inherit() CSS function method

The inherit() CSS function, which isn’t currently supported by any web browser, will enable us to get the value of a parent’s property. Think: the inherit keyword, except that we can get the value of any parent property and even modify it using value functions such as calc(). The latest draft of the CSS Values and Units Module Level 5 spec defines how this’d work for custom properties, which wouldn’t really enable us to do anything that we can’t already do (as demonstrated in the previous example), but the hope is that it’d work for all CSS properties further down the line so that we wouldn’t need to use custom properties (which is just a tad longer):

header {
  height: 3rem;

  button {
    height: 100%;

    /* Get height of parent but use it here */
    border-radius: calc(inherit(height) * 0.3);
    padding-inline: calc(inherit(height) * 0.5);
  }
}

There is one difference between this and the custom properties approach, though. This method depends on the fixed height of the parent, whereas with the custom properties method either the parent or the child can have the fixed height.

This means that inherit() wouldn’t interpolate values. For example, an auto value that computes to 3rem would still be inherited as auto, which might compute to something else when inherit()-ed., Sometimes that’d be fine, but other times it’d be an issue. Personally, I’m hoping that interpolation becomes a possibility at some point, making it far more useful than the custom properties method.

Until then, there are some other (mostly property-specific) options.

The aspect-ratio CSS property

Using the aspect-ratio CSS property, we can set the height relative to the width, and vice-versa. For example:

div {
  width: 30rem;

  /* height will be half of the width */
  aspect-ratio: 2 / 1;

  /* Same thing */
  aspect-ratio: 3 / 1.5;

  /* Same thing */
  aspect-ratio: 10 / 5;

  /* width and height will be the same */
  aspect-ratio: 1 / 1;
}

Technically we don’t “get” the width or the height, but we do get to set one based on the other, which is the important thing (and since it’s a ratio, you don’t need to know the actual value — or unit — of either).

The currentColor CSS keyword

The currentColor CSS keyword resolves to the computed value of the color property. Its data type is <color>, so we can use it in place of any <color> on any property on the same element. For example, if we set the color to red (or something that resolves to red), or if the color is computed as red via inheritance, we could then declare border-color: currentColor to make the border red too:

body {
  /* We can set color here (and let it be inherited) */
  color: red;

  button {
    /* Or set it here */
    color: red;

    /* And then use currentColor here */
    border-color: currentColor;
    border: 0.0625rem solid currentColor;
    background: hsl(from currentColor h s 90);
  }
}

This enables us to reuse the color without having to set up custom properties, and of course if the value of color changes, currentColor will automatically update to match it.

While this isn’t the same thing as being able to get the color of literally anything, it’s still pretty useful. Actually, if something akin to compute(background-color) just isn’t possible, I’d be happy with more CSS keywords like currentColor.

In fact, currentBackgroundColor/currentBackground has already been proposed. Using currentBackgroundColor for example, we could set the border color to be slightly darker than the background color (border-color: hsl(from currentBackgroundColor h s calc(l - 30))), or mix the background color with another color and then use that as the border color (border-color: color-mix(currentBackgroundColor, black, 30)).

But why stop there? Why not currentWidth, currentHeight, and so on?

The from-font CSS keyword

The from-font CSS keyword is exclusive to the text-decoration-thickness property, which can be used to set the thickness of underlines. If you’ve ever hated the fact that underlines are always 1px regardless of the font-size and font-weight, then text-decoration-thickness can fix that.

The from-font keyword doesn’t generate a value though — it’s optionally provided by the font maker and embedded into the font file, so you might not like the value that they provide, if they provide one at all. If they don’t, auto will be used as a fallback, which web browsers resolve to 1px. This is fine if you aren’t picky, but it’s nonetheless unreliable (and obviously quite niche).

We can, however, specify a percentage value instead, which will ensure that the thickness is relative to the font-size. So, if text-decoration-thickness: from-font just isn’t cutting it, then we have that as a backup (something between 8% and 12% should do it).

Don’t underestimate CSS units

You probably already know about vw and vh units (viewport width and viewport height units). These represent a percentage of the viewport’s width and height respectively, so 1vw for example would be 1% of the viewport’s width. These units can be useful by themselves or within a calc() function, and used within any property that accepts a <length> unit.

However, there are plenty of other, lesser-known units that can be useful in a similar way:

  • 1ex: equal to the computed x-height
  • 1cap: equal to the computed cap height
  • 1ch: equal to the computed width of the 0 glyph
  • 1lh: equal to the computed line-height (as long as you’re not trimming or adding to its content box, for example using text-box or padding, respectively, lh units could be used to determine the height of a box that has a fixed number of lines)
Source: W3

And again, you can use them, their logical variants (e.g., vi and vb), and their root variants (e.g., rex and rcap) within any property that accepts a <length> unit.

In addition, if you’re using container size queries, you’re also free to use the following container query units within the containment contexts:

  • 1cqw: equal to 1% of the container’s computed width
  • 1cqh: equal to 1% of the container’s computed height
  • 1cqi: equal to 1% of the container’s computed inline size
  • 1cqb: equal to 1% of the container’s computed block size
  • 1cqmin: equal to 1cqi or 1cqb, whichever is smallest
  • 1cqmax: equal to 1cqi or 1cqb, whichever is largest

That inherit() example from earlier, you know, the one that isn’t currently supported by any web browser? Here’s the same thing but with container size queries:

header {
  height: 3rem;
  container: header / size;

  @container header (width) {
    button {
      height: 100%;
      border-radius: calc(100cqh * 0.3);
      padding-inline: calc(100cqh * 0.5);
    }
  }
}

Or, since we’re talking about a container and its direct child, we can use the following shorter version that doesn’t create and query a named container (we don’t need to query the container anyway, since all we’re doing is stealing its units!):

header {
  height: 3rem;
  container-type: size;

  button {
    height: 100%;
    border-radius: calc(100cqh * 0.3);
    padding-inline: calc(100cqh * 0.5);
  }
}

However, keep in mind that inherit() would enable us to inherit anything, whereas container size queries only enable us to inherit sizes. Also, container size queries don’t work with inline containers (that’s why this version of the container is horizontally stretched), so they can’t solve every problem anyway.

In a nutshell

I’m just going to throw compute() out there again, because I think it’d be a really great way to get the values of other CSS properties:

button {
  /* self could be the default */
  border-radius: compute(height, self);
  /* inherit could work like inherit() */
  border-radius: compute(height, inherit);
  /* Nice to have, but not as important */
  border-radius: compute(height, #this);
}

But if it’s just not possible, I really like the idea of introducing more currentColor-like keywords. With the exception of keywords like from-font where the font maker provides the value (or not, sigh), keywords such as currentWidth and currentHeight would be incredibly useful. They’d make CSS easier to read, and we wouldn’t have to create as many custom properties.

In the meantime though, custom properties, aspect-ratio, and certain CSS units can help us in the right circumstances, not to mention that we’ll be getting inherit() in the future. These are heavily geared towards getting widths and heights, which is fine because that’s undoubtedly the biggest problem here, but hopefully there are more CSS features on the horizon that allow values to be used in more places.


On Inheriting and Sharing Property Values originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Will AI Replace Human Project Managers? Not So Fast

1 Share
Whiteboard plan for the timeline of a project.

We live in an era where project data flows abundantly. Companies track time spent on code reviews, measure process delays when delivery gets blocked and forecast everything from bug counts to team burnout levels.

The infrastructure for metrics is impressive, but here’s the interesting part: Most of these tools still focus on analysis rather than action. They tell us what happened, sometimes predict what might happen but rarely step in to actively manage the work itself.

This gap between measurement and management is where AI is beginning to make its presence felt. As someone who has spent years in delivery management, I find myself increasingly curious about a fundamental question: Can AI move beyond generating dashboards and actually help orchestrate the daily rhythm of project delivery? More provocatively, will these tools eventually replace the human delivery manager altogether?

From Metrics to Management: Where We Are Today

The current state of AI in project management is remarkable but incomplete. We have sophisticated systems that can approximate project deadlines to a satisfactory degree, recognize patterns for discerning the onset of team burnout and compute refactoring quantities from code complexity data. All these are real improvements, particularly for organizations trying to make data-driven decisions about resource allocation and timeline creation.

But if you look closely at the actual day-to-day work of a delivery manager, you will notice that few AI tools tackle more than half of it. Consider the typical workday: It’s synthesizing knowledge from different sources, explaining technical innovation in terms stakeholders understand, navigating people dynamics within teams and exercising judgment when things inevitably go wrong. These tasks require context sensitivity, emotional intelligence and an ability to reconcile competing needs in ways that bare data analysis cannot.

The real question is not whether AI is capable of monitoring patterns of work — it clearly is — but whether it is also capable of going from observer to participant in the delivery process itself. Initial indications are that this transition is already occurring, but perhaps not the blanket, high-drama one popular narrative would have us expect.

The Emerging AI Toolbox for Delivery Managers

Several concrete applications are already changing the time allocation for delivery managers. Meeting notes are a straightforward example. AI tools can attend project meetings, capture main decisions and action items, and generate formatted reports that otherwise would be manual with post-meeting cleanup. That might sound like a small thing, but for anyone who has tried to actually participate in a meeting while simultaneously taking notes, the cognitive load this reduces will be obvious.

Report generation is another area where AI is coming into its own. Instead of extracting information from task trackers, compiling it into readable summaries and emailing status updates to clients and stakeholders manually, managers can increasingly rely on AI to perform that synthesis on their behalf. The tools scan review ticket status, identify blockers and produce sensible accounts of project progress. The generated reports still need to be read and approved by human beings and, in most instances, need contextual additions, but the heavy lifting beforehand happens automatically.

Perhaps more ambitiously, some teams are experimenting with AI-assisted project planning. You provide a high-level brief or requirements document, and the system generates a preliminary project plan complete with task breakdowns, dependency mapping and timeline estimates.

Similarly, AI can evaluate deadlines proposed by contractors by comparing them against historical data from similar projects, flagging estimates that seem unrealistic based on past performance patterns.

What makes these applications interesting isn’t just the time they save, though that matters. They create consistency in the way information is processed and communicated. A human manager having a difficult week might produce less thorough reports or miss important patterns in the data. AI maintains the same level of attention regardless of external pressures. This reliability has real value, particularly in complex projects where small oversights can cascade into larger problems.

Coming Next: Expanding the Scope of AI in Management

The near future likely holds more ambitious applications. Imagine AI systems that can actually conduct daily standups with your team. The tool checks in via chat or voice, collects updates on progress and blockers, identifies action items, assigns them to appropriate team members and tracks completion. It could monitor these conversations over time, detecting patterns that might indicate emerging problems like unclear requirements, scope creep or interpersonal friction.

Requirements gathering represents another frontier. AI could engage with clients to collect initial requirements, ask clarifying questions based on common ambiguities in similar projects and even generate preliminary solution options with trade-offs clearly articulated. The delivery manager would still make final decisions and handle sensitive negotiations, but the groundwork would be largely automated.

Plan monitoring through continuous team communication is another possibility. Rather than waiting for weekly status meetings, AI could maintain ongoing awareness of execution by processing chat messages, code commits and task updates. When actual progress diverges from the plan, it could flag the variance and even suggest adjustments based on available resources and competing priorities.

These capabilities would fundamentally shift the delivery manager’s role from hands-on coordinator to something more like a systems architect and team coach. Instead of spending time on information collection and synthesis, managers would focus on higher-order concerns like team development, strategic planning and handling the truly novel situations where patterns from the past provide limited guidance.

The Human Factor: Why Managers Still Matter

Here’s what I believe about the future of delivery management: AI will handle an expanding set of tasks, but the role itself will remain fundamentally human for the foreseeable future.

AI excels at activities that can be standardized, that involve pattern recognition across large data sets and that benefit from tireless consistency. It can process meeting transcripts faster than any human, generate reports without procrastination and maintain awareness of hundreds of project details simultaneously. These capabilities make it an extraordinarily valuable tool.

But consider what AI still struggles with. It can’t sense when a team member is genuinely struggling versus just having a bad day. It doesn’t understand the unspoken dynamics between a client and their organization that might explain why certain feedback feels contradictory.

It can’t make the judgment call that sometimes you should miss a deadline rather than burn out your team, even though the data might suggest otherwise. Most importantly, AI can’t take meaningful responsibility for decisions. When things go wrong, as they inevitably do in complex projects, someone needs to own the consequences and work through the fallout with stakeholders and team members.

The delivery manager’s role is evolving into something I think of as “first pilot” in an increasingly AI-assisted cockpit. The AI systems handle routine monitoring, flag potential issues and suggest courses of action.

The human pilot maintains ultimate authority, makes the difficult calls and takes responsibility for outcomes. This arrangement mirrors how automation has transformed airline cockpits without eliminating pilots, because certain types of judgment and accountability simply can’t be delegated to algorithms.

What does this mean practically? Delivery managers need to lean into the distinctly human aspects of their work. Team atmosphere and morale matter more, not less, when routine coordination gets automated.

Building genuine trust with clients and stakeholders becomes increasingly valuable when AI can handle transactional communication. Soft skills like empathy, negotiation, conflict resolution and the ability to make wise decisions under uncertainty become the core competencies that define successful managers.

The future of delivery management isn’t human or AI. It’s human and AI, each contributing what they do best to the shared goal of shipping great software. That future is already arriving, and it looks more like a partnership than a replacement.

The post Will AI Replace Human Project Managers? Not So Fast appeared first on The New Stack.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

AWS Local Development with .NET Aspire - Build a Serverless Notifications System - codewithmukesh

1 Share
In this hands-on guide, we will use .NET Aspire 13 and the latest .NET 10 SDK to build a cloud-ready notifications system that talks to real AWS services like DynamoDB, SNS, and SQS, while keeping the entire local development experience orchestrated from a single Aspire app host.
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Client ID Metadata Documents Are the Future of MCP Client Registration

1 Share
Discover why Client ID Metadata Documents are replacing Dynamic Client Registration in the Model Context Protocol ecosystem for better security.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Thanksgiving Sale

1 Share

Thanksgiving Sale: 25% Off Web Component Engineering

I’m wrapping up the year with a little thank-you to everyone who cares about the Web Platform and modern UI engineering.

From now through November 30, you can get 25% off my Web Component Engineering course when you use the discount code GRATITUDE25 at checkout.

👉 Visit the course page.

About the Course

The Web Component Engineering course is a self-paced, in-depth course that teaches modern UI engineering through the lens of Web Components and core Web Standards. It’s designed to help you move beyond “framework-only” knowledge and really understand the platform you’re building on.

What It Covers

  • Using and authoring Web Components
  • DOM APIs and working directly with the DOM
  • Modern CSS for real-world UI systems
  • Accessibility baked into component design
  • Form-associated custom elements and handling real forms
  • Design systems, tokens, and component libraries
  • Application architecture with Web Components
  • Modern tools and libraries (Storybook, Playwright, Lit, FAST, and more)

What You Get

  • 13 modules with over 170 videos, fully self-paced
  • An interactive in-browser learning app (no local setup required)
  • Runnable demos, slides, and downloadable notes
  • A certificate of completion you can share with your team or manager

Whether you’re building a design system, maintaining a complex front-end application, or just want to understand what’s really possible with modern Web Standards, this course is designed to meet you where you are and then push you to the next level.

Thanksgiving Sale Details

If you’ve been waiting for the right moment to dive into Web Components and modern UI engineering, now’s the time to enroll.

Happy Thanksgiving, and thanks for being part of the Web community. 🙏

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

EP253 The Craft of Cloud Bug Hunting: Writing Winning Reports and Secrets from a VRP Champion

1 Share

Guests:

Topics:

  • We hear from the Cloud VRP team that you write excellent bugbounty reports - is there any advice you'd give to other researchers when they write reports?
  • You are one of Cloud VRP's top researchers and won the MVH (most valuable hacker) award at their event in June - what do you think makes you so successful at finding issues? 
  • What is a Bugswat?
  • What do you find most enjoyable and least enjoyable about the VRP?
  • What is the single best piece of advice you'd give an aspiring cloud bug hunter today?

 Resources:

 





Download audio: https://traffic.libsyn.com/secure/cloudsecuritypodcast/EP253_not249_CloudSecPodcast.mp3?dest-id=2641814
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories