{ "version": "https://jsonfeed.org/version/1.1", "title": "dout.dev — Latest Posts", "home_page_url": "https://dout.dev/", "feed_url": "https://dout.dev/feed.json", "description": "Vanilla-first static blog with WCAG 2.2 AA accessibility", "language": "en", "authors": [ { "name": "Emiliano \"pixu1980\" Pisu", "url": "https://dout.dev" } ], "items": [ { "id": "https://dout.dev/posts/2026-04-22-how-to-write-agent-skills.html", "url": "https://dout.dev/posts/2026-04-22-how-to-write-agent-skills.html", "title": "How to Write Agent Skills That Actually Trigger", "summary": "The mistake most people make", "content_html": "

The mistake most people make

\n

Most bad skills are not bad because the instructions are weak. They are bad because the skill never loads at the right time, or loads for the wrong task.

\n

That is the main point I took from Anthropic's PDF, The Complete Guide to Building Skills for Claude, and it is also the point the Medium summary by Ruqaiya Beguwala gets most right. The description field is not marketing copy. It is routing logic written in prose.

\n

Anthropic's framing is Claude-specific, but the lesson generalizes cleanly to agent skills of any kind. A skill is not \"a prompt you saved somewhere.\" A skill is packaged operational knowledge with an activation rule.

\n

A skill is a router, a playbook, and a reference pack

\n

Anthropic defines a skill as a folder with an exact SKILL.md file plus optional scripts/, references/, and assets/. The useful idea is the three-level loading model:

\n\n

That is a better mental model than \"write one giant instruction file.\"

\n

For agent design, I would translate it like this:

\n\n

If you collapse all three into one document, the skill gets harder to trigger, harder to maintain, and more expensive to load.

\n

Start with one hard task, not broad coverage

\n

One of the better parts of the PDF is that Anthropic pushes two seemingly different ideas at once, and both are correct.

\n

First, define 2-3 concrete use cases before you start. Second, iterate on one challenging task until the agent can do it reliably, then extract the pattern into a skill.

\n

That is the right order.

\n

Do not start with \"project management assistant\" or \"software engineering copilot.\" Those are product categories, not skills. Start with something that has a visible outcome:

\n\n

If the outcome is narrow, you can tell when the skill works. If the scope is broad, everything looks vaguely plausible and you ship prompt soup.

\n

Write the trigger sentence first

\n

The most important field in the whole skill is still the description.

\n

Anthropic's PDF is very explicit here: the description must say what the skill does and when to use it. It should include concrete trigger phrases users might actually say, stay under 1024 characters, and avoid XML angle brackets because the frontmatter lands in the system prompt.

\n

The document also adds practical constraints that the summary article only mentions lightly:

\n\n

That level of specificity matters because skills fail for boring reasons more often than clever ones.

\n

A good description looks more like an API contract than a slogan:

\n
---\nname: db-migration-review\ndescription: Reviews database migration plans, flags backward-compatibility and rollout risks, and proposes safe sequencing. Use when the user mentions schema changes, backfills, migrations, rollbacks, or zero-downtime deploys.\nmetadata:\n  version: 1.0.0\n---

This is specific about the outcome, the scope, and the trigger language. That is what gives the model a chance to route correctly.

\n

Instructions should be executable, not inspirational

\n

Anthropic is also right about the body of the skill: vague verbs are useless.

\n

\"Validate the data before proceeding\" is not an instruction. \"Run python scripts/validate.py --input {filename} and stop on missing required fields or invalid dates\" is an instruction.

\n

The more critical the step, the less you should rely on ambiguous language. The PDF says this plainly in the troubleshooting section: for important checks, prefer a bundled validation script because code is deterministic and language interpretation is not.

\n

That is one of the most transferable ideas in the whole guide.

\n

A good skill body usually needs four things:

\n
    \n
  1. the ordered steps;
  2. success conditions for each step;
  3. examples of common requests;
  4. troubleshooting for common failures.
\n

A minimal structure is enough:

\n
# Database Migration Review\n\n## Step 1: Read the migration plan\nInspect the schema change, expected rollout path, and rollback strategy.\n\n## Step 2: Run deterministic checks\nExecute scripts/check_migration.py --plan {filename}\n\n## Step 3: Produce the review\nReturn risks, missing safeguards, recommended sequence, and rollback notes.\n\n## Troubleshooting\nError: Migration plan missing rollback path\nSolution: Stop and ask the user for rollback semantics before continuing

This is dull on purpose. Dull is good. Skills are operating manuals, not thought leadership.

\n

One subtle PDF note is worth keeping: \"take your time\" style performance notes work better in the user prompt than in the skill file. That matches my experience with agent systems generally. Routing and workflow belong in the skill. Session-specific emphasis belongs in the prompt.

\n

Pick a pattern on purpose

\n

The Anthropic PDF is strongest when it stops talking in abstractions and starts naming workflow patterns. It identifies five that show up repeatedly:

\n\n

That list is more useful than it sounds because each pattern implies a different structure.

\n

A sequential onboarding skill wants strict step ordering and rollback rules. A multi-system handoff skill wants phase boundaries and shared state. An iterative report skill wants explicit quality thresholds and a stop condition. A context-aware storage skill needs a decision tree. A compliance skill needs governance before action.

\n

If you mix these patterns without choosing one, the skill becomes mushy. It has tools, but no shape.

\n

Test activation, behavior, and value separately

\n

The testing section in the PDF is better than most AI workflow docs because it separates three different questions.

\n

First: does the skill trigger when it should? Anthropic suggests 10-20 obvious and paraphrased prompts, plus unrelated prompts that must not trigger. The rough target is 90% on relevant queries and 0% on clearly unrelated ones.

\n

Second: does the skill actually do the job? Run the same request 3-5 times. Compare structure, tool calls, and failure handling. If results wander too much, the instructions are under-specified.

\n

Third: is the skill better than not having the skill? Compare tool calls, token use, back-and-forth, and failed API calls. If the skill does not reduce friction or improve consistency, it is decorative.

\n

The PDF also gives one debugging trick that is almost embarrassingly useful: ask the model, \"When would you use the [skill name] skill?\" The answer reflects the description back at you. If the answer is vague, the routing is vague.

\n

This is also where the PDF goes beyond the Medium summary in practical detail. It recommends keeping SKILL.md under 5,000 words, moving deep material into references/, and being careful once you have 20-50 skills enabled at once. That is not a theoretical concern. Too many skills turn progressive disclosure back into context sludge.

\n

Distribution matters more than people think

\n

The summary article focuses on the zip-and-upload flow, which is fine for Claude.ai. The PDF goes further and treats distribution as product work.

\n

The recommended path is: host the skill on GitHub, keep a human-oriented README at the repo level, document why the skill plus your MCP integration are better together, and provide a quick-start guide with examples and screenshots.

\n

That is the right instinct even outside the Claude ecosystem. If people cannot tell what outcome the skill produces, they will not install it. If the setup guide only talks about folders and YAML, you are describing mechanics instead of value.

\n

The PDF also makes the API surface explicit. Skills can be managed through /v1/skills, attached through container.skills, and used through the Agent SDK, with the note that the Code Execution Tool beta is required. Even if you never touch Claude's API, the general lesson holds: skills are not just authoring artifacts, they are deployment artifacts.

\n

What I would keep if I were writing skills for any agent stack

\n

The Anthropic guide is nominally about Claude skills, but most of its best advice is really about agent design in general.

\n

I would keep five rules:

\n
    \n
  1. Write the routing sentence before the rest of the skill.
  2. Build around one observable workflow, not a role description.
  3. Keep the main file short and move depth into references or scripts.
  4. Put deterministic validation in code whenever failure is expensive.
  5. Test activation separately from execution and separately from business value.
\n

The simplest way to say it is this:

\n
\n

A good agent skill is not a prompt dump. It is a narrow workflow with strong routing, explicit steps, and enough structure to fail predictably.

\n
\n

That is the real takeaway from the PDF. The fancy part is not the packaging. The hard part is deciding what the agent should do, when it should do it, and what evidence counts as success.

\n

References

\n\n", "image": "https://dout.dev/assets/og/posts/2026-04-22-how-to-write-agent-skills.png", "date_published": "2026-04-22T00:00:00.000Z", "tags": [ "Ai-copilot", "Architecture" ] }, { "id": "https://dout.dev/posts/2026-04-21-when-markdown-is-a-cms-and-when-it-is-not.html", "url": "https://dout.dev/posts/2026-04-21-when-markdown-is-a-cms-and-when-it-is-not.html", "title": "When Markdown Is a CMS, and When It Is Not", "summary": "The useful distinction", "content_html": "

The useful distinction

\n

A recent OpenReplay piece, The Good And Bad Of Using Markdown As A CMS, makes a distinction that matters more than it first sounds. \"Markdown as a CMS\" can mean at least three different systems:

\n\n

Those are related, but they are not the same thing. The trade-offs move with each one.

\n

On dout.dev, the setup is plain Markdown plus front matter, a custom CMS pipeline, and an HTML-native template engine. No MDX. No admin UI. No database. That choice is excellent for some problems and the wrong answer for others.

\n

Where Markdown is still the right answer

\n

For developer-owned content, Markdown remains hard to beat.

\n

The obvious reason is version control. A post is a text file in Git. Diffs are readable. Rollback is trivial. Branches and pull requests already are the review workflow. If the site generator changes in five years, the content survives because the content format is not proprietary.

\n

The less obvious reason is maintenance. Raw HTML content ages badly. Inline styles accumulate. Broken nesting sneaks in. One-off classes appear for formatting hacks. Markdown constrains the authoring surface on purpose, and that constraint is usually a feature.

\n

For a blog, documentation site, changelog, or engineering handbook, this is a strong fit. The people writing are usually the same people maintaining the build, and the content itself is mostly narrative rather than highly relational data.

\n

Where plain Markdown stops being a CMS

\n

The OpenReplay article is right about the breaking points.

\n

Plain files do not give you content relationships for free. \"Posts by author\", \"localized variants\", \"schedule this for next Tuesday\", \"send it through approval\", \"let marketing edit it without Git\" - none of that is inherent in Markdown. At that point Markdown is a storage format, not the whole publishing system.

\n

This is also where a lot of Markdown debates get sloppy. People say \"Markdown cannot do X\" when what they really mean is \"a directory full of .md files without surrounding tooling cannot do X.\" That is true. It is also incomplete, because a project can add a lot of structure around Markdown before it reaches for a headless CMS.

\n

What dout.dev adds on top of Markdown

\n

dout.dev is not \"just Markdown files in a repo.\"

\n

The CMS layer reads front matter, normalizes content, derives slugs, builds tags, month archives, and series datasets, and generates pages from those derived records. The renderer also builds feeds, search data, and OG images. The image pipeline turns a normal Markdown image into a responsive <picture> with WebP sources, known dimensions, lazy loading, and a <noscript> fallback. Pull requests also get a built preview artifact, which is enough for review even though the site stays fully static.

\n

That changes the shape of the problem. For this project, Markdown is the authoring format, but the CMS is the surrounding pipeline:

\n\n

This is enough to bypass several of the usual complaints about Markdown-based publishing on a personal site. Structured taxonomies exist. Media handling exists. Preview exists. Parser behavior is consistent because there is one Markdown pipeline.

\n

What dout.dev still does not pretend to solve

\n

The system is better than plain files alone, but it is still intentionally narrow.

\n

It is not a good fit for non-technical editors. There is no admin UI. The workflow is still Git-first.

\n

It is not a good fit for approval-heavy editorial teams. There are drafts through published: false, local watch mode, and CI preview artifacts, but there is no role model, no approval chain, and no true scheduled publishing workflow today.

\n

It is not a good fit for localization-heavy content. The site is English-only, and that is a product decision as much as a technical one.

\n

It is not a good fit for dynamic or highly relational domains. Comments can be outsourced to Giscus, search can be client-side, and analytics can be added carefully. But if the core content is products, inventory, user-generated data, or frequently mutating records, a database-backed CMS or API is the correct tool.

\n

This is the part worth being honest about: dout.dev bypasses some Markdown problems by adding custom infrastructure, but it does not magically turn Markdown into a universal CMS.

\n

The practical rule

\n

The rule I would use is simple.

\n

Use Markdown when the content is text-first, developer-owned, and benefits from living next to the code. Use a headless CMS when the content is structured, multi-author, localized, workflow-heavy, or owned by people who should never have to think about Git.

\n

For dout.dev, Markdown is still the right source format because the project is a single-author editorial system with strong opinions about portability, accessibility, and static output. For a marketing team, product catalog, or newsroom, I would not stretch this model beyond its natural limits.

\n

Markdown is a great source format. It is sometimes a CMS. It is never all of the CMS by itself.

\n

References

\n\n", "image": "https://dout.dev/assets/og/posts/2026-04-21-when-markdown-is-a-cms-and-when-it-is-not.png", "date_published": "2026-04-21T00:00:00.000Z", "tags": [ "Architecture", "Markdown", "Static-site" ] }, { "id": "https://dout.dev/posts/2026-04-04-how-i-built-dout-dev.html", "url": "https://dout.dev/posts/2026-04-04-how-i-built-dout-dev.html", "title": "How I Built dout.dev", "summary": "The Goal: an editorial blog without runtime ballast", "content_html": "

The Goal: an editorial blog without runtime ballast

\n

When I started reshaping dout.dev, I was not interested in repainting the theme and calling it done. I wanted to build an editorial system that stayed close to the native web: markdown content, readable HTML templates, CSS with real design tokens, and JavaScript used only where it delivers a clear benefit.

\n

The guiding principle was simple: every part of the stack should do a precise job without turning the blog into an application that is more complex than the publishing problem actually requires.

\n

The pipeline: markdown in, static HTML out

\n

The flow starts with the files in data/posts. Each article uses front matter for description, tags, cover image, publication date, and additional metadata. From there, the in-repo CMS reads the files, normalizes the data, and converts markdown into HTML.

\n

Generating everything at build time lets me ship pages that are easy to host on GitHub Pages, with stable URLs, prerendered content, and no dependency on an application backend.

\n

A minimal CMS, but pointed in the right direction

\n

The CMS does only a few things, but it does them consistently:

\n\n

That part matters because it moves complexity into the build step instead of pushing it into the browser.

\n

A template engine shaped around the project

\n

Instead of adding a server-side rendering framework, I preferred a project-specific template engine with blocks, includes, loops, and conditionals. The syntax stays intentionally close to HTML so the templates remain readable even when the page logic becomes more layered.

\n

The practical advantage is that components such as cards, headers, pagination, and post layouts can be reused without giving up control over the final markup. That becomes especially useful when you want to do semantic refactors or accessibility audits.

\n

Design system first, pages second

\n

The CSS did not grow as a pile of local exceptions. I defined tokens, type scales, spacing, surfaces, focus states, and component relationships first. Only after that did I build the header, cards, article template, and archive views.

\n

That approach makes the blog easier to evolve: if the density changes, a type family shifts, or panels need different behavior, the update starts from the foundation instead of from a chain of page-level patches.

\n

Accessibility as a project constraint

\n

A large part of the work went into keyboard support, landmarks, semantics, and contrast. Posts now have focusable headings, a sidebar outline synchronized with scroll position, and quick shortcuts to reach the main content and the internal article navigation.

\n

The goal was not to bolt ARIA labels onto the result after the fact, but to make sure the final markup is already sensible by default.

\n

Progressive enhancement, not client dependency

\n

The interactive pieces exist, but they arrive after the document is already useful. Theme switching, reading preferences, client-side search, and the scrollspy all improve the experience without becoming prerequisites for reading the site.

\n

If JavaScript never starts, the content is still available, structured, and navigable.

\n

The part that matters most: publishing without friction

\n

In the end, everything converges on a build command that generates the static site, refreshes assets, and produces output that is ready to deploy. That lets me treat dout.dev like an editorial product: write, review, validate, and publish.

\n

For me, the point is not using a fashionable stack. The point is having a pipeline that leaves room to focus on the writing and on a frontend quality bar that can actually be measured.

\n

What comes next

\n

The foundation is finally in place: richer SEO, complete feeds, deeper accessibility passes, and more refinement in the editorial system are the natural next steps. The difference now is that each new milestone can land on a base that is much more solid and predictable.

\n", "image": "https://dout.dev/assets/og/posts/2026-04-04-how-i-built-dout-dev.png", "date_published": "2026-04-04T00:00:00.000Z", "tags": [ "Architecture", "Static-site", "Design-systems", "Accessibility" ] }, { "id": "https://dout.dev/posts/2026-03-31-welcome-to-dout-dev.html", "url": "https://dout.dev/posts/2026-03-31-welcome-to-dout-dev.html", "title": "Welcome to dout.dev", "summary": "Welcome to the New dout.dev", "content_html": "

Welcome to the New dout.dev

\n

Welcome to the brand new version of dout.dev! This blog has been completely rebuilt from the ground up using modern web technologies while maintaining a vanilla-first approach.

\n

What's New

\n

Zero Runtime Dependencies

\n

The new dout.dev runs entirely on vanilla JavaScript, CSS, and HTML. No frameworks, no runtime dependencies - just clean, fast, and accessible web standards.

\n

WCAG 2.2 AA Accessibility

\n

Every aspect of this blog has been designed with accessibility in mind:

\n\n

Modern Build Pipeline

\n

Behind the scenes, we use:

\n\n

Performance First

\n

The site is optimized for Core Web Vitals:

\n\n

Technical Highlights

\n

This blog showcases several interesting technical approaches:

\n
    \n
  1. Custom Template Engine - Built specifically for this use case
  2. Static Site Generation - All pages pre-rendered at build time
  3. Progressive Enhancement - Works without JavaScript, better with it
  4. Modern CSS - Using custom properties, grid, and modern features
\n

Looking Forward

\n

This rewrite sets the foundation for many exciting features planned for the future:

\n\n

Stay tuned for more updates and technical deep-dives into how this blog is built!

\n
\n

This post marks the beginning of a new chapter for dout.dev. Welcome aboard!

\n", "image": "https://dout.dev/assets/og/posts/2026-03-31-welcome-to-dout-dev.png", "date_published": "2026-03-31T00:00:00.000Z", "tags": [ "Blog", "Welcome", "Vanilla-js" ] }, { "id": "https://dout.dev/posts/2024-12-27-m4-template-test.html", "url": "https://dout.dev/posts/2024-12-27-m4-template-test.html", "title": "M4 Template Test - Cover Image e Syntax Highlighting", "summary": "Questo è un post di test per verificare tutte le funzionalità implementate nel M4 - Post Page.", "content_html": "

Questo è un post di test per verificare tutte le funzionalità implementate nel M4 - Post Page.

\n

Cover Image e Pinned Badge

\n

Questo post ha:

\n\n

Syntax Highlighting con syntax-highlight-element

\n

Testiamo il syntax highlighting per vari linguaggi:

\n

JavaScript

\n
// Esempio JavaScript\nconst blogPost = {\n  title: 'M4 Template Test',\n  author: 'dout.dev',\n  published: true,\n  tags: ['Test', 'M4', 'syntax-highlight-element'],\n};\n\nfunction renderPost(post) {\n  console.log(`Rendering: ${post.title}`);\n  return `<article>${post.title}</article>`;\n}\n\naddEventListener('DOMContentLoaded', () => {\n  // highlighting is handled by the local <syntax-highlight> web component\n});

CSS

\n
/* Esempio CSS con design tokens */\n.post-cover-image {\n  width: 100%;\n  height: auto;\n  border-radius: var(--border-radius-md);\n  box-shadow: var(--shadow-lg);\n  object-fit: cover;\n}\n\n.post-badge--pinned {\n  background: var(--color-accent-primary);\n  color: var(--color-text-on-accent);\n  padding: var(--space-2) var(--space-3);\n  border-radius: var(--border-radius-full);\n  font-size: var(--text-sm);\n  font-weight: var(--font-weight-medium);\n}

HTML

\n
<!-- Esempio HTML con Schema.org -->\n<article class=\"post\">\n  <header class=\"post-header\">\n    <div class=\"post-badge post-badge--pinned\" data-pinned=\"true\">📌 Post in evidenza</div>\n    <h1>{{ title }}</h1>\n    <div class=\"post-meta\">\n      <time datetime=\"{{ date }}\">{{ date | date:'%d %B %Y' }}</time>\n    </div>\n  </header>\n  <div class=\"post-content\">{{ content | raw }}</div>\n</article>

JSON

\n
{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"BlogPosting\",\n  \"headline\": \"M4 Template Test\",\n  \"description\": \"Post di test per M4\",\n  \"datePublished\": \"2024-12-27T10:00:00.000Z\",\n  \"author\": {\n    \"@type\": \"Person\",\n    \"name\": \"dout.dev\"\n  },\n  \"keywords\": \"Test,M4,syntax-highlight-element,Cover Image\"\n}

Bash

\n
#!/bin/bash\n# Script per build e test\necho \"Building CMS...\"\nnpm run cms:build\n\necho \"Starting dev server...\"\nnpm run dev

Funzionalità Testate

\n\n

La checklist M4 dovrebbe essere completamente implementata! 🎉

\n", "image": "https://dout.dev/assets/og/posts/2024-12-27-m4-template-test.png", "date_published": "2024-12-27T10:00:00.000Z", "tags": [ "Test", "M4", "Syntax-highlight-element", "Cover-image" ] }, { "id": "https://dout.dev/posts/2024-10-28-concerning-css-grid.html", "url": "https://dout.dev/posts/2024-10-28-concerning-css-grid.html", "title": "Introducing CSS Grid - The Future of Web Layout 🎨", "summary": "What is CSS Grid and why is it important?", "content_html": "

What is CSS Grid and why is it important?

\n

CSS Grid is a powerful technology for creating web layouts that has changed the way we think about user interface design. Unlike older methods like float or flexbox, CSS Grid offers a true two-dimensional grid for positioning elements, making layouts simpler, more powerful, and adaptable.

\n

How does it work?

\n

CSS Grid introduces a system of rows and columns, allowing you to create complex layouts with just a few commands. Here is a basic example of a grid with two columns and two rows:

\n
display: grid;\ngrid-template-columns: repeat(2, 1fr);\ngrid-template-rows: repeat(2, 200px);

With these few lines of code, we can structure our pages without using hacks or complicated markup.

\n

Key Benefits of CSS Grid

\n
    \n
  1. Two-Dimensional Design: Allows you to work with rows and columns intuitively.
  2. Simplicity and Flexibility: Positioning elements becomes more natural and less restricted.
  3. Powerful Alignment: With properties like justify-items and align-items, aligning elements is a breeze.
\n

A Practical Example

\n

Let's look at a practical example of using CSS Grid to create a basic layout for a web page:

\n
<div class=\"container\">\n  <header>Header</header>\n  <nav>Navigation</nav>\n  <main>Main Content</main>\n  <aside>Sidebar</aside>\n  <footer>Footer</footer>\n</div>

And the corresponding CSS:

\n
.container {\n  display: grid;\n  grid-template-areas:\n    'header header'\n    'nav main'\n    'nav aside'\n    'footer footer';\n  grid-template-columns: 1fr 3fr;\n  gap: 20px;\n}\n\nheader {\n  grid-area: header;\n}\n\nnav {\n  grid-area: nav;\n}\n\nmain {\n  grid-area: main;\n}\n\naside {\n  grid-area: aside;\n}\n\nfooter {\n  grid-area: footer;\n}

In this example, we use grid-template-areas to assign names to sections and define the layout structure in a readable way.

\n

Conclusions

\n

CSS Grid is an essential tool for every frontend developer. If you want to create modern, responsive, and easily maintainable layouts, CSS Grid is the way to go. Don't be afraid to experiment and play with grids: once you learn it, you won't look back!

\n

Do you want to learn more about how to use CSS Grid in your projects? Feel free to ask questions or share your experiments in the comments! 😊

\n", "image": "https://dout.dev/assets/og/posts/2024-10-28-concerning-css-grid.png", "date_published": "2024-10-28T10:00:00.000Z", "tags": [ "Css", "Web-design", "Frontend", "Grid-layout" ] }, { "id": "https://dout.dev/posts/2024-05-19-a11y-by-design.html", "url": "https://dout.dev/posts/2024-05-19-a11y-by-design.html", "title": "Accessibility by Design", "summary": "We live in an era where technology permeates every aspect of our daily lives. However, not everyone can benefit equally from these advancements. This is where Accessibility by Desi", "content_html": "

We live in an era where technology permeates every aspect of our daily lives. However, not everyone can benefit equally from these advancements. This is where Accessibility by Design comes into play, a fundamental approach that must be incorporated from the early stages of digital product development. But why is it so important? And what are the advantages it offers in terms of inclusivity, responsiveness, usability, and marketing?

\n

Inclusivity: A Social and Moral Goal

\n

Inclusivity is not just a buzzword; it is a fundamental principle of a fair and just society. About 20% of the world's population lives with some form of disability. Ignoring this significant portion of the population means excluding millions of people from accessing digital resources. Accessibility by Design ensures that our products are usable by everyone, regardless of their physical or cognitive abilities. This not only improves the quality of life for many people but also strengthens our social responsibility as a company.

\n

Responsiveness: Adapting to Everyone's Needs

\n

An accessible design makes digital products more responsive. This means that our software, website, or application can easily adapt to the diverse needs of users. Whether it's people with visual, auditory, motor, or cognitive disabilities, an accessibility-focused approach ensures that everyone can effectively interact with our product. This not only enhances the user experience but also ensures that there are no technological barriers to access.

\n

Usability: Improving the Experience for Everyone

\n

Often, accessible design brings significant improvements in overall usability. Features such as clear and readable text, adequate color contrasts, intuitive navigation, and audio/video descriptions not only help users with disabilities but also enhance the experience for everyone. A product that is easy to use is a successful product, capable of meeting the needs of a wide range of users.

\n

Marketing: A Competitive Advantage

\n

From a marketing perspective, Accessibility by Design offers extraordinary benefits. With 20% of the world's population consisting of people with disabilities, we are talking about a vast segment of potential users, stakeholders, operators, and customers. Ignoring this segment means missing out on a significant market opportunity. On the other hand, creating accessible products can set our company apart from the competition, positioning us as leaders in the industry and enhancing our reputation.

\n

Conclusion

\n

Adopting Accessibility by Design is not just good practice but a winning strategy that encompasses inclusivity, responsiveness, usability, and marketing. It is an investment that pays off handsomely, improving our corporate image, expanding our user base, and demonstrating our commitment to a more equitable and inclusive society.

\n

Let's make accessibility a priority and work together to create a digital future that is truly for everyone.

\n
\n

Accessibility by Design is not just a trend but a necessity. We are ready to make a difference. Join us on this journey toward a more inclusive digital world.

\n", "image": "https://dout.dev/assets/og/posts/2024-05-19-a11y-by-design.png", "date_published": "2024-05-19T00:41:22.000Z", "tags": [ "A11y", "Design", "Responsive" ] }, { "id": "https://dout.dev/posts/2023-01-01-say-hello-2023.html", "url": "https://dout.dev/posts/2023-01-01-say-hello-2023.html", "title": "Say hello to 2023 🎉", "summary": "Say hello to 2023 🎉", "content_html": "

Say hello to 2023 🎉

\n

Welcome to the new year! This is the first post of 2023, and we're excited to share our plans for the year ahead. Stay tuned for more updates and content coming your way!

\n
addEventListener('DOMContentLoaded', (e) => {\n  console.log(e);\n});\n\nanotherFunctionCallGoesHere({}, () => {\n  selectOther();\n});
", "image": "https://dout.dev/assets/og/posts/2023-01-01-say-hello-2023.png", "date_published": "2023-01-01T14:41:22.000Z", "tags": [ "Markdown", "Releases" ] }, { "id": "https://dout.dev/posts/2022-03-25-concerning.html", "url": "https://dout.dev/posts/2022-03-25-concerning.html", "title": "Concerning…", "summary": "Concerning Core Web Technologies", "content_html": "

Concerning Core Web Technologies

\n

I truly believe in the following idea:

\n
\n

Let the technologies do the job they were designed for

\n
\n

We'll explore in detail... Building a CSS codebase from scratch can be very hard, but also fun and productive.

\n
\n

Concerning UI/UX

\n

Analyzing and implementing a Design and its related User Experience can be one of the funniest and challenging things to do.

\n
\n

Concerning a11y

\n

Let' start with a basic concept...

\n
\n

We need to raise awareness about a11y

\n
\n

20-25% have some sort of disability or uses a screen reader

\n
\n

Concerning Responsiveness

\n

Responsiveness is a concept, an idea, to me is...

\n
\n

Reacting to the environment

\n
\n", "image": "https://dout.dev/assets/og/posts/2022-03-25-concerning.png", "date_published": "2022-03-25T00:00:00.000Z", "tags": [ "Generic" ] }, { "id": "https://dout.dev/posts/2022-03-24-welcome-to-dout-dev.html", "url": "https://dout.dev/posts/2022-03-24-welcome-to-dout-dev.html", "title": "Welcome to dout.dev", "summary": "Hi, I'm Emiliano \"Pixu\" Pisu.", "content_html": "

Hi, I'm Emiliano \"Pixu\" Pisu.

\n

I'm a \"vintage\" developer who loves to code and to share ideas, thoughts, knowledge.

\n

I'm starting this blog to talk and discuss about web-based technology, honestly most of times i'll focus in UI/UX, because i love it.

\n

However, in order to be able to talk about User Interaction, we'll need to discuss about:

\n\n

Let's start a new trip together in the world HTML, CSS and JS.

\n", "image": "https://dout.dev/assets/og/posts/2022-03-24-welcome-to-dout-dev.png", "date_published": "2022-03-24T00:00:00.000Z", "tags": [ "Generic" ] }, { "id": "https://dout.dev/posts/2022-03-22-building-dout-dev-blog-part-2.html", "url": "https://dout.dev/posts/2022-03-22-building-dout-dev-blog-part-2.html", "title": "Building dout.dev blog - Part II", "summary": "Building dout.dev blog - Part II", "content_html": "

Building dout.dev blog - Part II

\n", "image": "https://dout.dev/assets/og/posts/2022-03-22-building-dout-dev-blog-part-2.png", "date_published": "2022-03-22T00:00:00.000Z", "tags": [ "Html" ] }, { "id": "https://dout.dev/posts/2022-03-21-building-dout-dev-blog.html", "url": "https://dout.dev/posts/2022-03-21-building-dout-dev-blog.html", "title": "Building dout.dev blog", "summary": "Less is more!", "content_html": "
\n

Less is more!

\n
\n

I started

\n", "image": "https://dout.dev/assets/og/posts/2022-03-21-building-dout-dev-blog.png", "date_published": "2022-03-21T00:00:00.000Z", "tags": [ "Html" ] }, { "id": "https://dout.dev/posts/2022-03-18-css-properties-hierarchy.html", "url": "https://dout.dev/posts/2022-03-18-css-properties-hierarchy.html", "title": "CSS Properties Hierarchy", "summary": ":root { --border-radius: 5px; } .element { /* css custom properties */ --var--example: 1; ​ /* position */ position: absolute; inset: 0; /* top, right, bottom, left */ z-index: 1; ", "content_html": "
:root {\n  --border-radius: 5px;\n}\n\n.element {\n  /* css custom properties */\n  --var--example: 1;\n​\n  /* position */\n  position: absolute;\n  inset: 0; /* top, right, bottom, left */\n  z-index: 1;\n​\n  /* display */\n  display: block;\n  display: flex;\n  place-content: center;\n  place-items: center;\n  justify-self: unset;\n  gap: 1rem;\n\n  opacity: 1;\n  visibility: visible;\n​\n  /* box-model */\n  box-sizing: border-box;\n  width: 10rem;\n  aspect-ratio: 16 / 9;\n  padding: 1rem;\n  border: 0.1rem solid black;\n  border-radius: 0.4rem;\n  margin: 1rem;\n  outline: 0.3rem solid black;\n  outline-offset: 0.3rem;\n​\n  /* colors & background */\n  color: white;\n  background-color: black;\n  background-image: url();\n  box-shadow: rgba(50, 50, 50, 1);\n  filter: drop-shadow();\n​\n  /* text */\n  font-family: 'Courier New', Courier, monospace;\n  font-size: 1rem;\n  font-weight: 700;\n  line-height: normal;\n  white-space: nowrap;\n  text-align: center;\n  text-shadow: none;\n​\n  /* transform & animations */\n  transform: translate();\n  transition: opacity 300ms ease-in, width 500ms linear;\n  will-change: opacity, width;\n  animation: test 300ms forwards alternate-reverse;\n​\n  /* helpers */\n  appearance: none;\n  cursor: pointer;\n  pointer-event: none;\n​\n  /* pseudo elements */\n  &::after {\n  }\n​\n  /* variants & pseudo selectors */\n  &.error {\n    color: red;\n  }\n\n  &[aria-hidden=true] {\n    display: none;\n  }\n​\n  /* pseudo selectors */\n  &:hover {\n  }\n​\n  /* media queries */\n  @media screen and (width >= 1024px) {\n    /* repeat css hierarchy here */\n  }\n\n  /* ------------ children */\n  span {\n    /* repeat css hierarchy here */\n  }\n​\n  input {\n    /* repeat css hierarchy here */\n  }\n​\n  > * {\n    /* repeat css hierarchy here */\n  }\n}
", "image": "https://dout.dev/assets/og/posts/2022-03-18-css-properties-hierarchy.png", "date_published": "2022-03-18T00:00:00.000Z", "tags": [ "Html", "Css" ] }, { "id": "https://dout.dev/posts/2022-03-16-test-codepen.html", "url": "https://dout.dev/posts/2022-03-16-test-codepen.html", "title": "Testing CodePen", "summary": "See the Pen Pure CSS Slider using Scroll-Snap by blackmirror1980 (@blackmir", "content_html": "\n", "image": "https://dout.dev/assets/og/posts/2022-03-16-test-codepen.png", "date_published": "2022-03-16T00:00:00.000Z", "tags": [ "Markdown", "Cover-image" ] }, { "id": "https://dout.dev/posts/2022-03-12-you-can-edit-css.html", "url": "https://dout.dev/posts/2022-03-12-you-can-edit-css.html", "title": "You can edit CSS", "summary": "You can edit CSS", "content_html": "

You can edit CSS

\n", "image": "https://dout.dev/assets/og/posts/2022-03-12-you-can-edit-css.png", "date_published": "2022-03-12T00:00:00.000Z", "tags": [ "Markdown", "Cover-image" ] }, { "id": "https://dout.dev/posts/2022-03-03-marked-markdown-parser.html", "url": "https://dout.dev/posts/2022-03-03-marked-markdown-parser.html", "title": "Marked - Markdown Parser", "summary": "How To Use The Demo", "content_html": "

How To Use The Demo

\n
    \n
  1. Type in stuff on the left.
  2. See the live updates on the right.
\n

That's it. Pretty simple. There's also a drop-down option in the upper right to switch between various views:

\n\n

Why Markdown?

\n
<div></div>

It's easy. It's not overly bloated, unlike HTML. Also, as the creator of markdown says,

\n
\n

The overriding design goal for Markdown's\nformatting syntax is to make it as readable\nas possible. The idea is that a\nMarkdown-formatted document should be\npublishable as-is, as plain text, without\nlooking like it's been marked up with tags\nor formatting instructions.

\n
\n
div {\n}

Ready to start writing? Either start changing stuff on the left or\nclear everything with a simple click.

\n", "image": "https://dout.dev/assets/og/posts/2022-03-03-marked-markdown-parser.png", "date_published": "2022-03-03T15:41:22.000Z", "tags": [] }, { "id": "https://dout.dev/posts/2022-03-03-custom-grid-system.html", "url": "https://dout.dev/posts/2022-03-03-custom-grid-system.html", "title": "Custom Grid System", "summary": "Blog under construction", "content_html": "

Blog under construction

\n", "image": "https://dout.dev/assets/og/posts/2022-03-03-custom-grid-system.png", "date_published": "2022-03-03T14:41:22.000Z", "tags": [ "Markdown", "Releases" ] }, { "id": "https://dout.dev/posts/2022-02-25-you-can-express-tags-today.html", "url": "https://dout.dev/posts/2022-02-25-you-can-express-tags-today.html", "title": "You can use express tags… TODAY!", "summary": "HTML6 is coming, we know it very well, 'cause we're strongly waiting for features like described here.", "content_html": "

HTML6 is coming, we know it very well, 'cause we're strongly waiting for features like described here.

\n

Let's take a look

\n

Since the introduction of XHTML, naming tags anyway you want is possible and passes HTMl validators. Browser engines computes unknown element names as a normal block element.

\n

Which means you can code HTML like this:

\n
<logo>\n  <img src=\"http:/domain.ext/path/to/image.jpg\" />\n</logo>

Which also means you can code CSS (here SCSS) as this:

\n
logo {\n  width: 10rem;\n  aspect-ratio: 2 / 1;\n\n  img {\n    width: 100%;\n    object-fit: cover;\n  }\n}
\n", "image": "https://dout.dev/assets/og/posts/2022-02-25-you-can-express-tags-today.png", "date_published": "2022-02-25T00:00:00.000Z", "tags": [ "Html", "Css" ] }, { "id": "https://dout.dev/posts/2022-01-01-say-hello-2022.html", "url": "https://dout.dev/posts/2022-01-01-say-hello-2022.html", "title": "Say hello to 2022 🎉", "content_html": "

\"example

\n", "image": "https://dout.dev/assets/og/posts/2022-01-01-say-hello-2022.png", "date_published": "2022-01-01T14:41:22.000Z", "tags": [ "Markdown", "Releases" ] }, { "id": "https://dout.dev/posts/2021-03-08-a-new-post-with-a-new-cover.html", "url": "https://dout.dev/posts/2021-03-08-a-new-post-with-a-new-cover.html", "title": "A NEW post with a NEW cover image", "summary": "Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or", "content_html": "

Readability, however, is emphasized above all else. A Markdown-formatted\ndocument should be publishable as-is, as plain text, without looking\nlike it's been marked up with tags or formatting instructions.

\n

While Markdown's syntax has been influenced by several existing text-to-HTML filters -- including Setext, atx, Textile, reStructuredText,\nGrutatext, and EtText -- the single biggest source of\ninspiration for Markdown's syntax is the format of plain text email.

\n", "image": "https://dout.dev/assets/og/posts/2021-03-08-a-new-post-with-a-new-cover.png", "date_published": "2021-03-08T00:00:00.000Z", "tags": [ "Markdown", "Cover-image" ] } ] }