DEV Community: Hussein Al Hammad

The new Outlook for Windows

Hussein Al Hammad — Mon, 13 Mar 2023 17:00:29 +0000

On 17 May 2022, Microsoft announced the new Outlook for Windows, a version that will have a huge positive impact in the email space.

Now

For years, the Outlook for Windows desktop apps relied on proprietary technology to render HTML emails: their own Microsoft Word. The historic and business reasons behind that decision is not the topic of today, but its impact is.

Besides proprietary features that only work on Outlook for Windows, the rendering of HTML and CSS features is not always identical to the W3C specification. The Microsoft Word rendering engine had not kept up with the HTML’s living standard.

The result? Given the wide use of Outlook for Windows globally, email developers stuck with patterns only needed to ensure their HTML emails render well on Outlook for Windows. Because these patterns are not needed for emails to render well elsewhere, it’s an Outlook-first approach and not a user-first one.

The new Outlook for Windows

The new Outlook for Windows brings a fundamental change. It no longer uses Microsoft Word as a rendering engine, but a normal web browser engine.

Based on the initial testing of developers in the email community, it is reported to have an almost identical handling of HTML/CSS features to the web version of Outlook. This aligns with Microsoft’s goal to “bring consistency across our Windows and web codebases”.

It has been a multi-year effort to reach this point, and Microsoft has been betting on web technologies when developing new features for their Outlook apps across all operating systems for some time now. Finally, it’s now time for the HTML rendering to catch up with the rest of the app.

Availability

At the time of the announcement:

The new Outlook for Windows is available to Beta Channel users running Version 2205 (Build 15225.20000) or later.

However, it seems Microsoft is making the new version more accessible to more users as it can be downloaded and installed via its Windows App store.

The path forward

“Code like it’s the 90s” - an eternal joke that is reaching its expiry date. October 2026 is the month when Microsoft is ending support to the last version of Outlook that uses the Microsoft Word rendering engine. We can anticipate users to start using the new Outlook for Windows well before that date.

The step Microsoft is taking here makes the goal of enforcing some email standards more feasible. One of the key reasons we started the Email Markup Consortium last year was we believed the timing is right. This is a huge milestone in the email industry and we believe it is going to help us realize our vision.

电子邮件标记联盟简介 (EMC)

Hussein Al Hammad — Wed, 06 Jul 2022 08:41:22 +0000

This post was originally published in English. Translated by Muxiang Pajerski.

电子邮件标记联盟是什么？

电子邮件标记联盟 (EMC) 是一个由电子邮件行业内专业人士领导与组织的非营利社区组织，它致力于改善每个人的电子邮件使用与应用的体验。

发件人、收件人和电子邮件客户端的共同目标是改善用户体验，并最大程度的优化可达性、功能性、一致性和可靠性。然而，目前致力于达到这些共同目标的电子邮件行业内各环节缺乏合作，导致电子邮件最终在各个电子邮件客户端的结果不一致。

收件人应该能够轻松访问他们收到的每封电子邮件的内容，无论他们的设备、电子邮件客户端、辅助技术或互联网速度如何。结合创建与发送电子邮件的工具，电邮标记联盟 (EMC) 与电子邮件程序开发人员及电子邮件各客户端一起合作，将在电子邮件旅程的每一步推动这一愿景。

为什么需要这个联盟？

综上所述，电子邮件业内相关各方缺乏合作来达到实现这些共同目标的愿望。

EMC 并不是第一个尝试解决这个问题的组织和项目。过去也有一些组织和个人在这方面做出过一些努力，其中包括：

以上证明，相关各方的合作确实存在差距，电子邮件行业需要 EMC 这样的组织与项目来引导相关各方聚集一团，整合资源和力量一起合作达到我们的共同目标。

为什么EMC与以前的项目不同？

以前的项目得到过很好的支持，并对推动这个共同目标的进展有所帮助，但是，它们中的大多数目前已经停止了运作。

长久性

EMC 的目标之一是长久性。我们计划在运作 EMC当中，在现任各项目的负责人员离开时，该项目仍然能持续进行下去并得到有效的支持。为了实现这一点，我们把这个项目尽可能的开放给大众。所有的工作进程与资源都公开地发布在 GitHub 上，任何人都可以为这个项目贡献他们的专业知识和力量。

我们还在研究考虑一个长期性解决方案来应对电子邮件标记的持续性与新技术可能带来的新挑战。我们不希望只是短暂性地解决几个小问题，相反，我们致力于电子邮件的标准化与规范化并希望在未来的电子邮件领域里能持续保持这些标准与规范。

最佳时机

我们认为与之前的尝试相比，我们这个项目的时机更好。近年来，电子邮件社区大规模发展，各方协作也大大增加。由业内社区志愿者专业人员为社区推出的相关新项目不断涌现，例如庞大的 EmailGeeks（电子邮件极客） Slack 组、电子邮件专业女性社团、CanIEmail（我能邮件吗）、如何针对电子邮件客户端等等。

有效合作的根据

近年来的电子邮件客户端在 AMP for Email 等项目上协作并采用 BIMI 等标准证明了在电子邮件领域中相互竞争的各个供应商是可以一起合作的。

志愿者如何参与？

该项目是开源项目，你可以在 GitHub 上找到我们，任何人都可以贡献一份力量：

您可以即刻加入并参与现有的讨论
通过打开 PR 直接参与贡献
像任何开源项目中一样，你可以开始一个问题讨论

如果您想正式表示对项目的支持，您可以以个人或组织的身份申请成为 EMC 支持者。

如果您想更多地参与 EMC 项目和组织的发展，您可以个人或组织的身份申请成为 EMC 成员。

如果您代表一个组织机构并且想要赞助 EMC，请与我们联系。

EMC 管理员
马克·罗宾斯、侯赛因·阿尔·哈马德、爱丽丝·李

Introducing the Email Markup Consortium (EMC)

Hussein Al Hammad — Wed, 25 May 2022 08:06:19 +0000

What is the Email Markup Consortium?

The Email Markup Consortium (EMC) is a community-led group of industry professionals working to improve the email experience for everyone.

Senders, recipients, and email clients share the common goals of improving user experience, accessibility, performance, consistency, and reliability. However, currently there is a lack of cooperation in trying to achieve these goals leading to inconsistent results.

Recipients should be able to easily access the content of every email sent to them, regardless of their device, email client, assistive technology or internet speed. The EMC collaborates with developers, creation and sending tools, and email clients to drive this vision forward at every step of the email journey.

Why is this needed?

As stated above, there is a lack of cooperation between the relevant parties to work towards these shared goals.

EMC is not the first project to attempt to address this. There have been several efforts in the past including:

This highlights to us that there is indeed a gap and an on-going need for a project like EMC to help bring the relevant parties together and collaboratively work with them.

Why is this different to previous projects?

Previous projects gained good support and helped move things forward. However, most of them have now been shut down or just left mostly unused.

Longevity

One of the goals of the EMC is longevity. We are structuring the EMC so that when the current members have moved on, the project will still live and be supported. To achieve this, we’re making the project as open as possible. Everything is posted publicly on GitHub where anyone can contribute.

We’re also thinking about long term solutions for the continuing challenges of email markup as well as new challenges that may arise with new technology. We’re not looking to only fix a few bugs. Instead, we’re looking to develop standards and maintain those standards moving forward.

Timing

We think the timing of this project is better in comparison to previous attempts. In recent years the email community has grown massively and collaboration has hugely increased. There are new projects coming up all the time, built by the community for the community, such as the huge EmailGeeks Slack group, Women of email, CanIEmail, How to Target Email Clients, and many more.

Evidence of productive collaboration

Seeing email clients collaboratively work on projects such as AMP for Email and adopting standards like BIMI shows us that different competing vendors in the email space can indeed work together.

How can people get involved?

The project is open source and you can find us on GitHub where anyone can contribute:

You can start or join an existing discussion
Contribute directly by opening a PR
Open an issue like you would on any open source project

If you would like to publicly show your support for the project, you can apply to become an EMC supporter as an individual or an organisation.

If you would like to be more involved in EMC projects and the organisation’s direction, you can apply to become an EMC member as an individual or an organisation.

If you represent an organisation and you would like to sponsor EMC, please get in touch.

EMC Administrators
Mark Robbins, Hussein Al Hammad, Alice Li

The privacy concerns of the noscript land

Hussein Al Hammad — Sat, 27 Feb 2021 09:21:30 +0000

I have recently learned that deferred loading of <img>s with the loading attribute only works if JavaScript is enabled.

<img loading="lazy" src="/image.jpg" alt="" />

The MDN documentation notes that this is an anti-tracking measure:

Loading is only deferred when JavaScript is enabled. This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when.

While the purpose of this behaviour seems reasonable on the surface, it made me thinks about two things:

1. The goal of disabling JS

This anti-tracking measure assumes that a user's goal of disabling JS is to prevent websites from tracking them and their actions on pages. This assumption justifies loading more resources on the user's device even if they do not scroll far enough down a page to need them.

I can't personally speak of the intention of disabling JS, but I am unsure how I feel about disabling the feature when JS is disabled in order to prevent tracking. After all, web features get maliciously used all the time.

Disabling deferred loading on img[loading=lazy] can have a direct impact on the user. I can see a user disabling JS in the browser to save on mobile data while browsing. They may not need to scroll all the way down to all pages. That is; they may not need to download all the images on all pages they visit. In this case, the anti-tracking measure backfires.

2. The noscript tracking paths

There are plenty of user-behaviour tracking approaches that work without JS.

The loading attribute on iframe

The loading attribute also works on <iframe>s. The current implementation of the loading attribute on <iframe> works even when JS is disabled. iFrame tracking pixels can be used to workaround the anti-tracking measure on images.

The ping attribute on anchor tags

The ping attribute on an anchor tag is typically used for tracking. It accepts a space-separated list of URLs to which the browser sends POST requests when the link is followed:

<a
  href="/contact"
  ping="https://example.com/my-tracker https://example.com/my-other-tracker"
>
  Contact Us
</a>

The ping attribute works even when JS is disabled. It is disabled by default in Firefox though.

The noscript tag

The <noscript> element can be used to conditionally load different/additional tracking pixels when JS is disabled:

<noscript>
  <!-- add tracking pixels here -->
</noscript>

The CSS approach

CSS provides a number of ways to conditionally apply styles. It also provides a number of ways to load external resources such as images. So it is entirely possible to make use of this to track users without the need of JS.

Using media queries:

@media (prefers-color-scheme: dark) {
  #tracker {
    background-image: url(/my-tracker.png);
  }
}

Using feature queries and browser-specific prefixed CSS properties:

@supports (-webkit-overflow-scrolling: touch) {
  #tracker {
    background-image: url(/my-tracker.png);
  }
}

CSS also provides a number of ways to apply styles based on user interactions. For example, you can track some user actions in a similar manner to the above using pseudo-classes. And I'm sure there are more novel ways to make use of other CSS features for tracking.

Final thoughts

Built-in anti-tracking measures is a very nice goal in theory, but it seems very hard to implement without sacrificing something else in return.

So this begs the question: is "whether JS is enabled in the browser" the right criterion for enforcing built-in anti-tracking measures?

This article was first published on hussein-alhammad.com on 20 February 2021

Internationalised Domain Names

Hussein Al Hammad — Fri, 18 Dec 2020 09:27:45 +0000

I have recently launched a new website (wajad.art) with an internationalised domain name (IDN). The domain name and all the page paths are in Arabic, which makes things more fun given Arabic is written right to left (RTL).

Domain name is وجد.موقع, and موقع is the top-level domain (TLD), which is the equivalent to the site TLD.

A full URL example of page:

وجد.موقع/م/أساطير-خليجية

How do IDNs work?

Given the Domain Name System (DNS) has to use ASCII characters, they store IDNs as ASCII strings using Punycode, which is:

a representation of Unicode with the limited ASCII character subset used for Internet hostnames

So while my newly launched website's domain name is وجد.موقع, in the DNS it is stored in the Punycode equivalent:

xn--rgbg7e.xn--4gbrim

Fortunately, there are Punycode converters such as:

Domain Name vs Page Path

The IDNs use Punycode to work around the DNS limitation of only supporting ASCII characters. This does not apply to the rest of the URL. You can use Unicode characters in the page path.

MDN's What is a URL? is a good resource to learn the different parts of a URL.

Browsers

Unicode vs Punycode (ASCII)

When navigating to a website with an IDN via the browser address bar, both the Unicode (e.g. وجد.موقع) and the Punycode (e.g. xn--rgbg7e.xn--4gbrim) work.

Even if you typed in the Punycode in the address bar, web browsers may automatically convert the URL to the (human-friendly) Unicode equivalent if the URL meets the browser's IDN policy:

The goal of these policies is to protect users from IDN homograph attack. There are also browser extensions that alerts users if they are on a site that uses Punycode in its domain name.

Early this year, Google Chrome Developers YouTube channel's show HTTP 203 released an episode titled Humans can't read URLs. How can we fix it?. Jake and Surma briefly discuss how Chrome analyses the URL and when it may choose to display the Punycode over the Unicode.

RTL vs LTR

If you ever mixed RTL and LTR languages when typing something on a digital device, you'd certainly have experienced frustrating times attempting to get words to flow correctly. The browser address bar doesn't handle this too well either.

In the case of وجد.موقع, it is read RTL. However, adding the http protocol at the start means the address starts LTR. So you end up with:

https://وجد.موقع

Even if you set the language in the browser to Arabic, which converts the UI to RTL:

This is not a huge pain point, but it does look odd. As a developer I know the start is https://. However, to an Arabic speaker who is not familiar with the protocol and its uses, they may interpret this as the URL ends in https://.

This may be slightly off-topic, but it is worth noting that things become even more confusing if you use an ASCII domain name (LTR) with an RTL page path and vice versa:

وجد.موقع/path/to/page

xn--rgbg7e.xn--4gbrim/الصفحة-1/الصفحة-2

Copying the URL

When you are on a website with an IDN and copy the URL directly from the address bar, what gets copied into your clipboard varies across browsers.

Firefox (83.0) copies the Unicode:

https://وجد.موقع

Chrome's (87.0.4280.66) behaviour is more sophisticated. If you include the https protocol when you copy the URL from the address bar, it copies the Punycode into your clipboard:

https://xn--rgbg7e.xn--4gbrim

If you exclude the https protocol, it copies the Unicode:

وجد.موقع

The above behaviour only applies to the domain name. When it comes to the page path, the behaviour is also inconsistent across browsers.

Firefox (83.0) encodes the page path to its UTF-8 representation when the URL is copied (think JavaScript's encodeURI(), or PHP's urlencode()), which is a huge UX pain for me in general and not only with IDNs. Receiving a URL in a chat app that fills up half my phone's screen with %s and a mix of meaningless digits and English characters is pointless to me as a user.

https://وجد.موقع/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

On Chrome (87.0.4280.66), if the https protocol is included, it copies the Punycode domain name and the encoded page path:

https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

If the https protocol is excluded, it copies the whole URL in Unicode:

وجد.موقع/م/أساطير-خليجية

Sharing the URL

Web browsers on smartphones and tablets offer a built-in sharing option, which gives you the choice to copy the URL or share directly to native apps. The behaviour across browsers here is also inconsistent.

The same browser may not behave consistently when copying the URL from the address vs when copying/sharing the URL using the built-in share option. Samsung Internet (13.0.1.64), for instance, copies the Unicode (domain and page path) if you copy the URL directly from the address bar:

https://وجد.موقع/م/أساطير-خليجية

However, it copies the Punycode and the encoded page path when using the built-in share option:

https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

JavaScript

The Location API returns the domain name in Punycode and encodes page paths:

{
  "ancestorOrigins": {},
  "href": "https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9",
  "origin": "https://xn--rgbg7e.xn--4gbrim",
  "protocol": "https:",
  "host": "xn--rgbg7e.xn--4gbrim",
  "hostname": "xn--rgbg7e.xn--4gbrim",
  "port": "",
  "pathname": "/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9",
  "search": "",
  "hash": ""
}

The wilderness

I have used a number of services in which I had to enter the IDN for Wajad or on which the domain name is displayed.

Domain registration

Registering a domain with Punycode with a common TLD like .com is not an obstacle. Some domain registrars allow you to use Unicode when searching domains e.g. وجد.com.

But I was looking for the internationalised TLD موقع. It was not easy finding a domain registrar that sold موقع domains. I ended up on multiple scammy-looking sites during my search. Eventually I bought the domain via maracaria.com.

Cloudflare

I had no issues adding IDNs with Unicode when adding the site to Cloudflare. They are also displayed in Unicode in the dashboard:

However, Cloudflare used the Punycode in the email notifications they sent to me so far:

Netlify

Before launching the site, I set up a "coming soon" landing page on Netlify. Unlike Cloudflare, Netlify did not allow me to add the domain name with Unicode, and I had to enter the Punycode equivalent. Netlify's dashboard displays the domain in Punycode:

Their email notifications also display the domain in Punycode:

Cloudways

Wajad's current PHP-based site is hosted on DigitalOcean via Cloudways. The experience on Cloudways is similar to Netlify and I had to enter the Punycode:

Google Search Console

I was able to add the site to Google Search Console with the Unicode version of the domain. Oddly, some subsequent forms did not accept Unicode:

So I had to enter the Punycode equivalent, but Google Search Console displayed the URL in Unicode after submitting the form:

Fortunately, email notifications use Unicode:

Google Search results

Google Search results display the domain name in Unicode. I already knew it displayed Arabic correctly for breadcrumbs, but it is really nice to see the domain name displayed in a human-friendly manner:

Both Unicode and Punycode are supported when using search operators like site::

site:وجد.موقع

site:xn--rgbg7e.xn--4gbrim

Bing Webmaster Tools

Bing Webmaster Tools allow you to import verified sites from Google Search Console. Upon an import attempt it displayed an error message saying the site addition was unsuccessful:

I attempted to enter the URL manually as suggested, but the Unicode was not accepted:

Then when I went to check the list of sites under my account, Wajad was actually listed! I'm not entirely sure which of the above attempts was the successful one.

Bing Webmaster Tools lists the domain in Unicode, but when you open the dashboard for the site it lists the Punycode:

I had the opposite experience to Google Search Console when submitting the sitemap. The form accepted the Unicode, but the sitemap list displays the Punycode:

Bing search results

I have only recently submitted the sitemap via Bing Webmaster Tools, so I still do not know the full picture. From what I can tell so far Bing search results also display the domain in Unicode.

However, it seems only Punycode is supported when using search operators like site::

site:xn--rgbg7e.xn--4gbrim

Fathom Analytics

I had no issue using the Unicode version of the domain when adding the site to Fathom Analytics. The domain is always displayed in Unicode (dashboard and email notifications).

Their recently-launched tool Phantom Analyzer also allowed me to enter the URL in Unicode, but the results page displayed the domain in Punycode.

Zoho Mail

Neither Unicode nor Punycode is supported when signing up to Zoho Mail.

Emails

G Suite (now Google Workspace) allowed me to sign up with my IDN. I sent test emails to Gmail, Yahoo and Outlook. Gmail was the only one to display the domain name in Unicode.

I have also sent HTML email tests with images. Yahoo Mail and Windows Mail did not load images whose src had the domain in Unicode, but Gmail did:

<img src="https://وجد.موقع/path/to/image.jpg" alt="">

Auto-linking

When sending messages via chat apps, adding the https protocol to the URL (with domain name in Unicode) seems to be enough for most apps.

Although email clients are known for linking text in HTML emails when you don't want them to, I found Gmail and Windows Mail don't auto-link:

https://وجد.موقع

In-app browsers

The behaviour of in-app browsers is consistent. On iOS, Instagram's in-app browser displays the domain in Punycode, while Twitter's in-app browser displays the domain in Unicode.

I understand, but..

I understand why I'm seeing very different behaviour across browsers and apps, but as a developer and a user I just would love to see a better user experience overall.

Wajad is still a young side project, but it is clear to me that I'll run into more interesting IDN-related scenarios as it grows and I'll try my best to document them.

This article was first published on hussein-alhammad.com

RTL support lands in Bootrstrap and Bulma

Hussein Al Hammad — Sat, 18 Jul 2020 14:01:20 +0000

On 7 June 2020 Bulma v0.9.0 was released and while I always wanted the spacing helpers it introduced, what I was most excited about is the RTL support!

Shortly after, Bootstrap 5 alpha was released and they also announced RTL support!

I live in a part of the world where it is becoming extremely common for websites and web apps to offer both English (LTR) and Arabic (RTL) versions. Seeing popular CSS frameworks add built-in support for RTL is a huge plus for many developers in this region, and I certainly hope more open-source projects follow suit.

Having said that, I do realise my role in this and I feel developers (including me) who want to see RTL support in more open-source projects should be contributing to such projects (if they have the required skill set); particularly if it is a small project with a single or very few maintainers.

Alpine.js: responsive x-cloak

Hussein Al Hammad — Fri, 03 Apr 2020 12:59:30 +0000

When using Alpine.js the x-cloak attribute is removed from DOM elements when Alpine is initialised. As noted in the docs, this makes it useful for hiding elements until Alpine is initialised:

x-cloak attributes are removed from elements when Alpine initializes. This is useful for hiding pre-initialized DOM. It's typical to add the following global style for this to work:
<style>
  [x-cloak] { display: none; }
</style>

You may want to hide pre-initialised DOM on some screen sizes, but not others. A good example for this is the links in a site's navigation bar, which are typically hidden by default on smaller screen sizes, but are always visible on wider screens.

So instead of hiding all elements with the x-cloak attribute, we can hide only the ones whose x-cloak attribute has no value:

[x-cloak=""] { display: none; }

This allows us to target elements whose x-cloak attribute has a value:

[x-cloak="some-value"] { }

So now we can write CSS rules targeting elements whose x-cloak value is mobile, tablet, desktop:

/* always hidden */
[x-cloak=""] { display: none; }

/* hidden on mobile/smaller screens */
@media screen and (max-width: 768px) {
    [x-cloak="mobile"] { display: none; }
}

Bidirectional horizontal rules in CSS

Hussein Al Hammad — Tue, 22 Oct 2019 10:34:51 +0000

The dir attribute in HTML and the dir property in CSS can be used to set the direction of text and horizontal flow. Some languages are written Left-To-Right (LTR), while others are written Right-To-Left (RTL). So having this level of control is vital for creating documents and interfaces for the web.

Building an interface to support both LTR and RTL layouts is a challenge. Flexbox and Grid certainly makes things easier, but they don't cover all our styling needs.

There are many CSS rules we write in which we specify a physical direction or side. For instance, when we write CSS to layout horizontal elements, it is common to set a margin only on a single side and set a margin of 0 (on the same side) to the first or last sibling element.

.element {
    margin-right: 1rem;
}

.element:last-child {
    margin-right: 0;
}

.element:not(:last-child) {
    margin-right: 1rem;
}

In the above example we are adding a margin on the right side of each element except the last. That's how it is written. Though what we mean when we write this is to add a margin after the element in the direction of the horizontal flow of the document (or the parent element).

A common way to style blockquote is to add a border to one side of the quote; the side we consider to come before the quote.

This is Bulma's <blockquote> styling:

.content blockquote {
    background-color: #f5f5f5;
    border-left: 5px solid #dbdbdb;
    padding: 1.25em 1.5em;
}

And there are many other styling choices we make in which we specify a side/direction (left/right) in CSS, but what we actually mean is before/after.

So when building interfaces that support both LTR and RTL layouts, one option would be to write CSS rules like:

.class {}

html[dir="rtl"] .class {}

Or perhaps even load different stylesheets for LTR and RTL layouts. However, both options require we either write more CSS or set up our tooling to generate the appropriate flipped styles. And there are also tools that convert LTR to RTL styles for you.

Wouldn't it be nice to work with a lower level of abstraction instead? What if we can tell the browser we are targeting the side before/after an element instead of referring to the physical directions left/right? At the end of the day this is what we mean a lot of the times. This reminds me of this tweet:

keith•j•grant

@keithjgrant

When you code CSS, you’re writing abstract rules to take *unknown* content and organize it in an *unknown* medium. That shit is hard.

13:26 PM - 17 Mar 2017

CSS has what is called logical properties. We can now tell the browser what we actually mean. Instead of using -left and -right, we can use -inline-start and -inline-end:

.element:not(:last-child) {
    margin-inline-end: 1rem;
}

Similarly instead of using -top and -bottom, we can use -block-start and -block-end.

This means we can write one set of rules that target both LTR and RTL layouts. Here is an example using the margin-inline-end property:

Using the border-inline-start and padding-inline-start properties:

Firefox also supports border-*-*-radius so you can target different corners with border-start-start-radius, border-end-start-radius, etc.

All demos:

For a deeper explanation, you can refer to Rachel Andrew's article Understanding Logical Properties And Values. This is not just about RTL interfaces or horizontal bidirectional CSS rules. Rachel's article also covers logical dimensions.

Browser Support

Can I Use?:

Every developer builds a CMS!

Hussein Al Hammad — Wed, 25 Sep 2019 11:03:00 +0000

"Every developer eventually builds a CMS" is a joke I came across enough times that I promised myself I wouldn't do it. Although I think the joke often comes from developers who have been in the industry for a lot longer than I have, and perhaps enough of them either built or came across custom CMS solutions.

Luckily, we are no longer in the era in which building a bespoke CMS is common for one-off projects. On the other hand, while there are many CMS products in the market we are very much in the era of using (or repurposing) SaaS applications as headless Content Management Systems.

Many applications have nice interfaces, customisable data structures, native mobile apps and developer-friendly APIs. Some even have built-in field types! The ability to build custom extensions provided by some applications also open doors to fill in any gaps in order to utilise them as CMS solutions.

CMS has a competition

Content has a new potential home. CMS products have competition from products that are not classified as a CMS or site builders and, in many cases, not built to solve the same problems. These products can perform many of the same tasks and some may even out-perform traditional CMS products in some aspects.

The bar is a little higher for CMS products nowadays. The expected feature list is a bit longer ranging from built-in third-party integrations to real-time collaboration and from customisability to ease-of-use.

The CMS target audience no longer compares a CMS product only against other CMS products, but also against other digital products. A Content Management System is a digital product after all. When users are exposed to a wider range of digital products and find a feature has become so common amongst these products, they may eventually expect the average CMS to support it too.

What can you use as a CMS?

There are several products you can use as a CMS:

Google Drive
Google Sheets
Airtable / more Airtable / Aritable + Gatsby / even CSS-Tricks has an article on using Airtable as a CMS
Trello
Evernote

Zenkit, a SaaS product that offers a good deal of customisability, even suggests on their website that you can use the product as a CMS:

Don’t just manage projects – create a CRM, CMS, ERP, or anything else you need.

And you probably can create your own custom headless CMS solution using Zoho Creator, a low-code platform.

Not a one-size-fits-all

As with almost everything in the tech world, using a digital product that isn't a CMS to manage and deliver content to websites does not suit all use cases. I'm not claiming that. However, this approach is certainly viable.

We've seen site builders compete against CMS products and services such as Squarespace and Wix now serve a market that otherwise would rely on a CMS to power their websites. We've seen many developers ditch CMS solutions in favour for static site generators when possible. So I don't think it is too crazy to consider some SaaS products as alternatives to content management systems, especially when a product like Airtable can also be used for managing other aspects of a business (e.g. project management, CRM).

I do, however, think the headless CMS scene has great options. So unless a company is already using a product for managing other aspects of the business, it probably makes more sense to pick a tool that was designed for managing and delivering content.

If you were to use a SaaS product as a headless CMS, what product would you choose?

Favourite albums to listen to while coding

Hussein Al Hammad — Sun, 18 Nov 2018 10:43:25 +0000

Like many developers I often put my headphones on when coding. It helps me get in the zone, block out other distractions and get into that flow state.

Not all types of music helps me though. I find what works for me best is listening to instrumental albums, particularly progressive rock/metal. The tracks feel structured and often flow nicely.

And the flow is not just on a track-by-track basis. The whole album just flows and, as a result, so do my thoughts. So I don't play these on shuffle (who plays albums on shuffle?). I also occasionally play them at the gym too!

Below is a list of my favourite instrumental albums to listen to while coding. And here's a Spotify playlist containing them all.

DEV Community: Hussein Al Hammad

The new Outlook for Windows

Now

The new Outlook for Windows

Availability

The path forward

电子邮件标记联盟简介 (EMC)

电子邮件标记联盟是什么？

为什么需要这个联盟？

为什么EMC与以前的项目不同？

长久性

最佳时机

有效合作的根据

志愿者如何参与？

Introducing the Email Markup Consortium (EMC)

What is the Email Markup Consortium?

Why is this needed?

Why is this different to previous projects?

Longevity

Timing

Evidence of productive collaboration

How can people get involved?

The privacy concerns of the noscript land

1. The goal of disabling JS

2. The noscript tracking paths

The loading attribute on iframe

The ping attribute on anchor tags

The noscript tag

The CSS approach

Final thoughts

Internationalised Domain Names

How do IDNs work?

Domain Name vs Page Path

Browsers

Unicode vs Punycode (ASCII)

RTL vs LTR

Copying the URL

Sharing the URL

JavaScript

The wilderness

Domain registration

Cloudflare

Netlify

Cloudways

Google Search Console

Google Search results

Bing Webmaster Tools

Bing search results

Fathom Analytics

Zoho Mail

Emails

Auto-linking

In-app browsers

I understand, but..

RTL support lands in Bootrstrap and Bulma

Alpine.js: responsive x-cloak

Bidirectional horizontal rules in CSS

Browser Support

Every developer builds a CMS!

CMS has a competition

What can you use as a CMS?

Not a one-size-fits-all

Favourite albums to listen to while coding

1. (II) by Toundra

2. Mozaic by Sunset in the 12th House

3. Back to Earth by Exxasens

4. Boundless by Long Distance Calling

5. (III) by Toundra

6. O by The Gentle Art of Cooking People