Author Archive for: admin

Original Source: https://www.smashingmagazine.com/2020/03/css4-pros-cons-discussion/

Why Are We Talking About CSS4?

Why Are We Talking About CSS4?

Rachel Andrew

2020-03-04T11:30:00+00:00
2020-03-04T13:07:05+00:00

There has been some discussion recently about whether there should be a CSS4, as in a defined “next version” of CSS. In this article, I take a look at the discussions around this, the pros and cons of creating a feature release for CSS, and the potential problems in deciding what goes into it.

I’m using the term CSS4 as that is how the discussion was started, and not attempting to discuss what the naming should actually be, should this approach be taken forward. Bikeshedding naming is an excellent distraction from the discussion of whether we should do this at all, so I will use CSS4 as a placeholder for the version of CSS we are proposing to define, and CSS5 for the next one along the line.

The Issue

A discussion around whether we should define a CSS4 has been raised in the community, and Jen Simmons then raised a CSS Working Group issue which neatly rounds up some of that existing debate. Outside of the actual issue that we are discussing, it is fantastic to see so many people who are not part of the CSS WG replying on this thread, and I hope that having commented once, people will be happy to come and comment on some of our other issues.

In order to understand why there is no CSS4, we need to look at a little bit of web platform history. The initial versions of CSS were as a single, monolithic specification. These specifications contained every possible CSS property and value. This worked well as there wasn’t a lot of CSS to detail. CSS1 mostly covered features for formatting text documents, additional features and clarifications were added to CSS2 and CSS2.1 however CSS was still a relatively small specification.

CSS3

At the point the CSS Working Group began work on CSS3, it was decided to split the big spec into modules. These modules would each cover part of CSS. Not all of CSS was immediately placed into a new module. Many things remained defined in CSS2.1 as there were no changes or additions to them. For this reason, you will still find links to the CSS2 specification in modern modules, if the thing that is being referenced is still defined in CSS2. However, any new CSS is created in separate modules. This modularization continues today as new CSS is being created. For example, several of the features that make up the Box Alignment specification initially started life in the Flexbox spec. Once it became apparent that they could apply to other layout methods such as Grid Layout, they were moved into a new module to be defined for that other method too.

We stopped referring to new specifications as CSS3 Specifications, partly because it didn’t make a lot of sense. The way that modules are versioned is that the modules which were a progression of CSS2, for example Selectors, became a Level 3 module. Brand new CSS, for example CSS Grid Layout, did not exist at all in CSS2 and so start life as a Level 1 module. Some of those initial modules are now at Level 4 or even Level 5. Therefore, calling all new CSS CSS3 doesn’t map to the level numbers anymore, and is potentially rather confusing.

Specification Maturity Levels

In addition to specification levels, each individual level goes through a staged process from the initial draft to becoming a W3C Recommendation, the steps in the process are referred to as Maturity Levels. A W3C Recommendation is what you might think of as a “web standard”, however many of the things we use daily in our work are defined in specifications that are not at that maturity level yet. You can see the list of specifications and their status on the CSS WG Current Work page.

Explaining The Missing CSS4

Many of us involved with the process saw the confusion about CSS3 or the apparent lack of progress to CSS4 and began to write articles, post videos, and try to help people understand a bit about how the process actually worked. That said, while it was important to share this information so that people teaching CSS would explain it correctly, I am not sure how much this information matters to the average web developer. What level a specification is at, or the internal W3C process of specification maturity, is far less important to a web developer than the issue of what CSS can actually be used in browsers.

“There Is No Such Thing As CSS4,” Tab Atkins-Bittner
“Why There Is No CSS4: Explaining CSS Levels,” Rachel Andrew
“Where Is CSS4? When Is It Coming Out?,” Layout Land (video)

What Are The Benefits Of Versioning CSS?

Looking through the responses to the issue, and the discussion around the web, there are certainly some potential benefits of having a clear version number for CSS.

As a writer of books and a producer of educational materials, I would probably benefit from CSS version numbers. It’s an excuse to publish an updated book that covers the latest and greatest version of CSS. On the other side of that, it is a way for the purchasers of books and courses to be sure that what they are buying is reasonably up to date – although the publishing date is arguably a better indication of that than anything else.

One thing we did lose by moving away from a version number of all of CSS, was the ability to do something like the Acid Test. The Acid 1 Test tested for support of CSS1, Acid 2 for support of CSS2.1. These tests were reasonably well known and seen as a good benchmark for browser support of web standards. A version 3 test was developed, however, it tested for a range of features and was less tightly tied to the Level 3 CSS Modules than previous tests had been to CSS1 and 2.1. A definite line drawn around a set of features would allow for user agents to declare their level of support for those features.

Some commenters on the issue have mentioned that a version would allow them to push for dropping of older browser versions because they “don’t support CSS4”.

“[…] perhaps CSS4 could help to push their mindset towards a more secure and better web. During pitch meeting, it’s hard to tell them we can’t support IE10 because we want CSS Variables and Grid Layout. Stakeholders do not know and do not care. They just want to support as many browsers as they could (very typical FOMO mindset) and they have the dollars to throw.

However, if we could tell them we can’t support IE10 because it doesn’t have the latest CSS4 technology and throw them the “Are you sure you want your newly created website to be behind your competitors because of that?” question, that might ponder them (of course, on top of the fact that IE10 is completely obsolete and vulnerable).”

There is an argument that defining a version gives developers a clear set of things to learn. In opening the issue on the CSS WG Jen Simmons said,

“I see a lot of resistance to learning the CSS that came after CSS3. People are tired and overwhelmed. They feel like they’ll never learn it all, never catch up, so why try, or why try now? If the CSSWG can draw a line around the never-ending pile of new, and say ‘Here, this. This part is ready. This part is done. This part is what you should take the time to learn. You can do this. It’s not infinite.’ I believe that will help tremendously.”

What Are The Problems Of Versioning CSS?

The first issue is that any collection of “ready for the primetime” CSS, is not as straightforward as selecting a set of specifications. Many specifications are partially implemented, with great support for some properties and none for others. There are features which many web developers would see as mature, sat in specifications still at Working Draft status alongside features which are still being debated and clarified in the Working Group.

If we take Multiple-column Layout as an example. The majority of properties have had widespread browser implementation for many years. However, the column-span property has only recently been implemented in Firefox, and there are a number of features that have recently been clarified, such as column-fill.

We could decide to ignore specifications altogether and look at properties. That isn’t straightforward either due to the fact that we have partial implementations across layout methods. The Box Alignment Properties are an excellent example. These are defined for all layout methods, where the property makes sense in that layout method. However support for Box Alignment is currently only seen in Grid and Flexbox. Therefore is justify-self, which is defined for block-level boxes, absolutely-positioned boxes, and grid items stable? Yes in a Grid context, no in a Block Layout context.

Box Sizing is another area, we have support for the intrinsic sizing value fit-content() in CSS Grid Layout for track sizing, yet not as a value for width. Then, none of the intrinsic sizing keywords are implemented for flex-basis by browsers other than Firefox.

Finally, if we return to multicol, many of the problems people have with multicol are nothing to do with the properties themselves, but are to do with poor support of fragmentation across browsers. This makes multicol seem to behave badly despite there being excellent support of the various properties. Disentangling all of these dependencies to come up with a set of features is going to be quite a difficult job.

CSS Is Not Just For Web Browsers

As I and one other commenter have mentioned, CSS is not just for web browsers. There are a whole raft of user agents that take CSS and HTML and output printed documents by way of creating a print-ready PDF. They typically have excellent support for the Paged Media specification, fragmentation and so on. However, they often lag behind browsers in terms of implementing newer CSS, for example Grid Layout. How do they fit into CSS4?

People Expect A Feature Release To Include Currently Non-Existent Features

Something interesting that has happened in the discussion on the issue, is that a number of people have commented saying that their expectations of a CSS4 are that it would contain certain features that are not yet part of CSS at all. Joshua Lindquist, in his excellent roundup of the comments notes that,

“When discussing authors that do not keep up with the latest developments, I think this approach will be simple to understand. Everything will feel like it’s brand new to them, even though some of these features, like Grid and Flexbox, have been in browsers for years.

But anyone who does keep up will likely be confused about why there is a ‘new’ specification full of things that are actually old.”

Who Would Decide What Makes The Cut?

Given the fact that the features that would make up CSS4 are not completely straightforward, someone is going to have to make the decision as to what is included.

The CSS Working Group has criteria for stability via the Maturity Levels already discussed. Once a spec has two implementations of each feature it can progress from Candidate Recommendation Status to become a Recommendation. However, as detailed above, it can take some time for that to happen, and while we are waiting for some features in a spec to have implementations, other may have widespread and stable browser support. If we were to say that CSS4 was only those specifications that were at Recommendation Status it would include:

CSS Color Level 3
CSS Namespaces
Selectors Level 3
CSS Level 2 Revision 1
Media Queries
CSS Style Attributes
CSS Fonts Level 3
CSS Writing Modes Level 3
CSS Basic User Interface Level 3
CSS Containment Level 1

So, no Grid, Flexbox, Box Alignment, and many more specifications that most of us are using.

If we are going to define a version of CSS, that is separate to the existing specification levels and maturity that we already have as part of the W3C process, then there needs to be a group with the time and resources to work on this. That group not only needs to define CSS4, but needs to do that as part of developing a framework to make these decisions this time, and for the next n versions of CSS. Otherwise, we will be having this discussion again in another two years, about the fact that no-one has shipped CSS5. I don’t believe the CSS Working Group is the right venue for that, even if only that there is other work that the WG needs to be doing to actually develop and define new CSS. There are already more jobs to be done than we have time to do. In addition, having another consideration when working on specifications will make decisions around each spec harder. Currently, we have situations where parts of a spec are marked as at-risk if their inclusion might prevent the spec from progressing to a Recommendation. It was for this reason that subgrid was bumped to Level 2 of Grid. If we have this additional level of abstraction, which doesn’t really fit into the process, will this just be another thing to consider and thus delay work on specifications?

What Problem Are We Trying To Solve?

In many of the responses to this issue, web developers brought up browser support as being key to what should be included in a CSS4, and I think that the issue we face is less one of CSS versioning and more of web developers being clear as to which collection of features should generally be considered usable in their projects.

“One of the advantages of a CSS4 approach is that it signals two things. First, that there’s a significant bundle of new CSS features that have been developed after CSS3 and which are ready for use and second, that they are ready for use. Not experimental or implemented by Chrome but no one else, but ready for broad adoption.”

— Rick Gregory

The fact that browser support comes up so frequently in this discussion makes me wonder if a better place to be defining this would be somewhere like MDN. MDN is already contributed to by all browser vendors, it already has support data for these features in a way that allows us to see partial implementations of things like Box Alignment. MDN is the documentation for the web platform, so we could sidestep the issue of print implementations, or any other implementations of CSS, scoping the feature set to the web alone.

I remain unconvinced that a CSS4, or whatever we choose to call a version of CSS, will actually make any difference to the perception of CSS outside of a relatively small community. Nor do I think it will help to solve the problems that web developers have in terms of convincing their bosses and clients to upgrade browsers. If Microsoft, who provides the software, is telling companies to upgrade and companies are not upgrading, I fail to see what the carrot of supporting CSS4 will do. And, I’ve been doing this a long time and know that back when we did have versions of CSS, people still didn’t upgrade their browsers. However, I think it will make it easier to talk about a particular chunk of functionality in a less abstract way, but I think that it needs to happen outside of the CSS Working Group and the specification process, and be based on what is usable as opposed to what is well specified.

“However, I must agree with several others that major marketing versions only have meaning in a compatibility situation. If we announce that CSS5 is finally here, it must mean all major browsers have full or near-full support.

Without this compatibility condition met, I think some developers will be cynical, and return to feature or module based thinking, the current status quo.”

— Ferdy Christant

What Do You Think?

I wanted to bring the discussion to Smashing Magazine as I think that many of our readers won’t have noticed this discussion. I’d be interested in what you think. Are there ways in which declaring a version of CSS would help you, that I haven’t mentioned here? Would checking to see what was in this version be something you would do, or would you be more inclined to check Can I Use, or MDN to find out what is supported? Do you think the average web developer cares about this stuff? Let us know in the comments, post to the original issue, or join the new Community Group set up to discuss this.

(il)

Original Source: https://www.sitepoint.com/how-to-design-for-screen-readers-with-adobe-xd-cc/?utm_source=rss

When it comes to accessibility, designers tend to focus on colors (i.e. contrast) and UX copy (i.e. wording), whereas developers tend to focus on ARIA attributes (i.e. code that makes websites more accessible). This is due to the fact that, often enough, thick lines are drawn between “who does what”.

Also, because creating accessible apps and websites isn’t considered to be exciting, this line is hardly ever questioned.

Accessibility is still a black sheep, even in 2020.

So, since UX copy is the responsibility of the designer and ARIA attributes are the responsibility of the developer, exactly whose responsibility is it to cater for screen readers? Since:

Screen reader UX copy is expressed as Braille or dictation (so how do we communicate this when our UI tools are visual?)
Implementation is developer territory (so can we really shift the responsibility of writing UX copy to developers?)

As you can see, it’s a two-person job — and yet, the tools simply don’t exist to facilitate this. I mean, make no mistake, some aspects of accessibility design are one-sided (for example, UI designers can very easily take care of color contrast by themselves). However, other aspects such as designing for screen readers requires collaboration between designers and developers.

This is where Adobe XD CC’s design handoff and voice prototyping features come in handy. In this article, we’ll discuss what to consider when designing for screen readers, and we’ll also walk through how to use the features mentioned above.

What Are Screen Readers?

A screen reader is a type of assistive technology that communicates what’s happening on the screen (for those with visual impairments). Screen reader software can be used in combination with the keyboard (for example, users will tab and enter as opposed to using the mouse), but it can also be used in combination with screen reader hardware, which allows for more efficient navigation and also caters for users that use Braille.

If you’re an Apple user, for example, you’ll be somewhat aware of Apple VoiceOver, which is the native Apple dictation software that acts as a screen reader. Windows users, however, commonly use either JAWS or NVDA, since there aren’t any native screen reader tools in the Windows operating system.

Let’s dive in.

1. Use Headings

Screen readers often use headings as a way of deciphering a website’s structure, and if we think too visually we run the risk of leaving out these headings. In the example below, the omission of the “Chapters” heading causes screen readers to assume that the list of chapters is a continuation of the content on the left-hand side, which it obviously isn’t.

As a result, screen-reader users won’t be able to skip to “Chapters”, and they might not discover the information within.

While there are code workarounds available (such as the aria-label attribute), having a visible heading inclusively offers a clearer experience for everybody, whether disabled or not.

Of course, the section is very obviously a list of chapters, as we can infer from the context (i.e. the content). However, those using screen readers very rarely have the luxury of context. It’s like trying to find an object in storage where none of the boxes are labeled. Our designs need these labels and headings.

On the technical side, the rule is that every section (as defined by a <section> or <article> tag) should have not only a heading, but an explicit heading that conflicts with no other heading. As an example, if the highest level heading within a section is an <h2>, then there should be no other <h2> heading within that section. Otherwise, screen readers are clueless as to which heading is the label for the section.

The post How to Design for Screen Readers with Adobe XD CC appeared first on SitePoint.

Original Source: https://www.hongkiat.com/blog/react-js-web-developers-toolkit/

The popularity of React.js has been rapidly growing since Facebook first released the library back in 2013. It’s the fifth most frequently starred open source project on Github, and job ads for…

Visit hongkiat.com for full content.

Original Source: https://www.webdesignerdepot.com/2020/02/5-simple-responsive-blunders-and-how-to-avoid-them/

Nearly 49% of all the web traffic worldwide originates from mobile devices (excluding tablets). If you don’t design mobile-friendly websites, you’ll likely lose out on this massive chunk of your target audience. Additionally if you wish to improve your SEO, you can’t afford to ignore smartphones; Google gives priority to mobiles with mobile-first indexing.

All of this calls for responsive web design through which your website’s elements can adjust according to the screen dimensions. While creating your responsive design, you might end up making some common mistakes. To help you avoid them, we’ve put together some possible responsive design pitfalls and their solutions below.

1. Using Device Sizes as Breakpoints

According to OpenSignal, there were over 24,000 different Android devices in 2015; this number has increased in the past five years. As there are so many varieties device, the screen dimensions differ vastly too. To ensure that your website offers a seamless browsing experience on all devices, you need to get your breakpoints right. 

If you concentrate on just device size breakpoints in your responsive design, your website may not appear correctly on newer devices. Don’t restrict yourself to the dimensions of current devices for breakpoints. Instead, go for truly responsive designs that can adjust well on any screen size. 

If you concentrate on just device size breakpoints in your responsive design, your website may not appear correctly on newer devices

A great idea is to take up the mobile-first approach where you build your website for the smallest screens and then slowly scale it to larger screen sizes. If wearable devices are important for your website, you should start your designing with those instead. 

As you’re scaling up, your website design may start feeling strained. In such a situation, you can add media queries to it for making necessary changes. This will help your design remain comfortable at each step. You need to continue this process until you reach the largest screen sizes. Ideally, this would be up to 2800 pixels as most users have resolutions lower than this. 

Using this method, your breakpoints will be introduced only when they’re needed and not according to the device size. This can help you offer a seamless browsing experience to your visitors across all devices. You can use tools like LambdaTest or BrowserStack to check if your website renders well on new devices.

2. Not Considering File Sizes

Visual elements can make your website more attractive to users. However, you must be careful when you’re adding them to your website. They are typically larger than text files and can slow down your page loading speed. As your page loading time increases, so do your bounce rates. In fact, according to Akamai, the bounce rates increased by 6% when pages took 1.5 seconds more to load during the 2017 holiday season. 

It is thus necessary to optimize your images and videos to reduce their sizes. You could use tools like TinyPNG or  Compress JPEG to achieve this. If you’re a WordPress user, you can install the Smush plugin to get this work done for you. 

Minifying your CSS, HTML, and JavaScript files can help as well. You should also consider browser caching, which can increase page loading speed for return visitors. Lastly, remove all unnecessary 3rd party tools and JavaScript dependencies. To check your current page loading speed and find possible solutions, you can use Google PageSpeed Insights. You could also use the Mobile Site Speed Tool from Google to see how quickly your website loads on mobiles.

3. Not Using Adaptive Image Management

While the file size of an image is important, so are its dimensions. You may not worry about using images of different dimensions in conventional website design. However, when it comes to responsive design, missing out on image management can be catastrophic for your user experience. The last thing you’d want your visitors seeing is huge images on a small screen.

To avoid this pitfall, you should use adaptive image management techniques. You could go for the following methods to achieve this:

Resolution-based selection: Provide the same image with different resolutions;
Device-pixel-ratio-based selection: Make the images appear crisp and reduce perceptible artifacts based on screen sizes;
Viewport-based selection: Vary images based on devices used and their orientation;
Art direction: Change or crop the image based on the display to improve its viewing experience.

4. Hiding Content

missing out on image management can be catastrophic for your user experience

One of the biggest mistakes that you can make while creating a responsive design of your website is that of hiding content. You might do so to fit your website on a smaller screen or to increase your page loading speed. However, you must avoid it at all costs. Remember, people aren’t coming to your website just to look for a small sample. They want the same browsing experience that they get on desktops.

Your goal should be to provide them with this omnichannel experience. This is necessary because many of them may be accessing your website from multiple devices during a day. That’s why you must ensure that you maintain consistency of content in responsive design. You can, of course, prioritize the content differently across devices through progressive enhancement.

5. Keeping Consistent Navigation

Giving a consistent browsing experience to your visitors across all devices is of the utmost importance. However, absolute consistency isn’t good either. One of the biggest mistakes you can commit while trying to do this is that of keeping consistent navigation across all screen sizes. 

When your screen size reduces, a consistent navigation bar may end up occupying half the screen and might spoil the browsing experience altogether. You should consider shrinking the navigation with the screen size and could change it to a hamburger menu.

 Along with your navigation, button sizes and visual layouts should not remain consistent either. However, typefaces, links, and color treatments should be consistent. 

Final Thoughts

If you wish to reach your entire target audience, you can’t avoid responsive design. However, you must be careful while implementing it and avoid all the possible errors. Give your visitors a consistent browsing experience across all devices and don’t hide any information from them. Optimize your file sizes to improve your page loading speed. Additionally, use adaptive image management techniques to reduce or increase the image dimensions according to the screen sizes. 

Don’t keep your navigation consistent as it may spoil the browsing experience. The same rule applies to buttons and visual layouts too. Lastly, go for truly responsive designs and don’t restrict yourself to design breakpoints based on current devices. The key is to go mobile-first when you’re designing your website.

Featured image via Unsplash.

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Original Source: http://feedproxy.google.com/~r/abduzeedo/~3/o2ib596A4bg/amazing-polestar-precept-concept-car

The Amazing Polestar Precept Concept Car

abduzeedoFeb 27, 2020

Electric cars are the future, at least that’s what it looks like from all the amazing electric car companies and models being announced. I am a fan and the desire of having a Tesla keeps coming and going. Now Polestar announces this amazing concept car, the Polestar Precept and boy it’s a thing of beauty. Tiago Aiello shared some images on his Behance profile and I was blown away. Maybe I will hold on a bit longer to see how many more car makers announce, there’s the new Hummer coming as well. As I said, it looks like the future is going to be electric.

Precet: a rule intended to inform behaviour or thought. In other words, a way of declaring how you mean to proceed. Starting as you mean to go on. Stating your intentions up top. A manifesto. It’s also the name for something that takes all of our ambitions and combines them.

Concept Car