The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

Latest articles

Minutes Telecon 2020-09-23

Source: CSS WG BlogDael Jackson • 23 September 2020

Full Meeting Minutes

Minutes Telecon 2020-09-16

Source: CSS WG BlogDael Jackson • 16 September 2020

Full Meeting Minutes

Making video pages for the W3C AC meeting

Source: W3C Blog Bert Bos • 13 September 2020

Most of the preparation for the May meeting of W3C’s Advisory Committee was already done when it became clear that travel was not going to be possible, due to COVID-19. It had to be a ‘virtual’ meeting. But because you cannot ask people to be in a video conference eight hours a day, the usual presentations were replaced by recorded videos that the participants could view in their own time before the meeting.

Prerecorded video talks

As every year, W3C had planned a meeting of its Advisory Committee in the spring of 2020. It was going to be on 18 and 19 May, in Seoul, South Korea. Most of the preparation was already done when at the beginning of March it became clear that travel was not going to be possible, due to COVID-19. The decision was made to hold a ‘virtual’ meeting, i.e., a meeting by video conference.

You cannot ask people to be in a video conference eight hours a day for two days, and so the format was changed to two discussion sessions of an hour and a half, and the usual presentations replaced by recorded videos. The participants could view the videos at their leisure during the preceding week.

We asked the presenters to film themselves or record just their audio. We also asked them to film themselves only as a ‘talking head’ and rely on slides for all visuals. Those slides had to be in HTML and meet our accessibility requirements. (As for all such meetings, we already had prepared the graphical style for the slides earlier and provided the speakers with a template; we just had to remove the word ‘Seoul’ from it.) This ensured a homogeneous set of talks with maximum accessibility, even for people who watched the presentation on a small screen, where the video had to be reduced in size.

To make the videos even easier to follow, we also made transcripts, closed captions, and even subtitles in three languages (Korean, Japanese and Simplified Chinese). And we developed HTML pages to serve as the user interface to the videos.

We did not create translated transcripts, for two reasons: We think that the people who make up the audience, although they may have difficulty understanding some English speakers, can all read English pretty well; and, secondly, it would have required more people to do the editing.

Indeed, several people expressed their appreciation of the translated subtitles, but nobody mentioned missing translated transcripts.

[screenshot]

(Reduced) screenshot of a medium-size browser window with the slides and the transcript on the left and a small video on the right.

The HTML pages allow different ways to watch the talks: read the slides and the video transcript, play the video in a corner of the screen while reading the slides and the transcript, or watch a synchronized slide show and video side by side (‘kiosk mode’). The video can display captions or subtitles. When watching the slide show, the captions or subtitles are shown under the slides, because the subtitles in the video can be quite small and because we expect that people have their eyes more on the slides than on the video. By default, the page shows the English captions, but the user can select the other languages, or turn the captions off.

[screenshot]

(Reduced) screenshot of a maximized browser window, showing ‘kiosk mode‘: one slide on the left, the video on the right and subtitles (here in Korean) under the slides.

One presentation, the opening remarks by the Director, did not have slides. In this case we showed the video where otherwise the slides would be.

To make the captions and the subtitles, we hired the services of a specialized company. That gave us captions in the WebVTT format with good timing, although the text did need some editing. Many speakers in our videos were not native speakers of English and several talks were technical in nature, which is probably the reason why some words were not correctly transcribed and some punctuation was wrong. The English captions needed a little editing, the translations needed more.

The first talk available (slides and video) was the one by my colleague Coralie Mercier. She made a video in which she spoke slowly and clearly, and announced each slide explicitly. That video, and its set of captions, was a great help when developing the technology to make the transcripts and the HTML pages for each talk.

A team effort

Reviewing and editing the captions was done in part by the speakers themselves, and in part by the W3C team. For the English captions, that posed few problems: Many people in the team could contribute and many also had enough technical skills to edit the caption files directly. (All the captions were stored in the repository that serves our web site.) The number of people who could review and edit the translated subtitles was obviously much smaller, especially for the more technical talks.

There were some minor hiccups when people used an HTML editing tool to edit the captions. We use a particular HTML WYSIWYG editor often because it allows us to update our web site through HTTP PUT. However we had no such tool for editing WebVTT files. The HTML editor worked but required us to remove some extraneous HTML headers after editing.

There were 19 talks, varying in length from 4 to 29 minutes, totaling just over 4 hours. Some people who reviewed the translated subtitles reported that they spent 12 hours reviewing and correcting them. Maybe hiring a different agency, one that has more experience with technical subjects, can reduce that time. Or we could prepare a glossary in advance with technical words the speakers are likely to use.

The video transcripts were made from the English captions. One of my colleagues, Dominique Hazaël-Massieux, used a small script (in JavaScript) to concatenate the captions from a WebVTT file, add some HTML markup, and save the result. He also added some markup by hand to mark the places where the speaker switched to a new slide. Most of the speakers were careful to announce each slide and even if they forgot one, it was usually pretty clear what slide they were on.

The manual markup consisted just of starting a new <div> element at each slide boundary. That was enough to match each part of the transcript to the corresponding slide when the HTML page for each talk was generated.

Project management

We did not use a project management tool to synchronize the work. It is something we may look into the next time, although we know it is hard to find something that everybody likes.

Instead, we used a variety of tools, according to people’s preferences, but none very intensively: GitHub issues, a wiki, CVS, email… Occasionally we chatted during existing meetings when there happened to be two or three people interested in the videos. The only deadline set in advance was the date when all presentations would be published.

The whole process took six weeks, from creating the agenda and inviting the speakers to publishing the video pages, and ended on May 10, as hoped.

Hosting the videos

The videos were used pretty much as the speakers delivered them, as a single take. We did very little editing.

Six speakers chose to record only audio, thirteen made a video. Most people used their laptop to record themselves, some used a camera setup in their office.

To keep the user interface the same for the talks with only audio, another colleague of mine, Ralph Swick, converted the six audio files to videos by combining the audio with a static image. We needed to do that, because we used a particular video player and there was no audio player with the same UI.

Indeed, WebCastor, already a sponsor of two W3C TPAC meetings, offered to host the videos on their StreamFizz platform. That saved us from storing the videos locally and made them available via their CDN and in multiple resolutions.

Unfortunately, it also meant that we had to load all captions into the video page twice. The captions inside the video are not accessible to the script of the page, because of the ‘same-origin policy‘. (Our script loaded the second set of captions with the XmlHttpRequest() function in JavaScript and parsed them with Anne van Kesteren’s a WebVTT parser.)

The StreamFizz video player provides relatively coarse synchronization (via ‘timeupdate’ events). Slides and captions may start or end up to half a second too early or too late.

The player does not provide a link to download the video and watch it offline and we did not provide one either.

Accessibility and the default user interface

A page that is combined by a program from various pieces made by different people who didn’t see the final result, and which on top of that has scripts that modify the contents in reaction to user actions, has a high risk of not being very usable. We therefore asked the accessibility experts in our team for feedback early on. Several gave helpful comments, but special mention goes to Josh O’Connor and Daniel Montalvo, who wrote an accessibility review and helped choose the correct ARIA attributes to use.

We found out that the help text inside the video player was not accessible. The problem was that the description of each key and the key itself were visually, but not structurally separated. Assistive technology didn’t pronounce the key as a separate letter. We passed on that feedback to WebCastor and made our own help text.

There appeared to be a difference of opinion between people relying on the visuals and those relying on assistive technology, with respect to one aspect of the pages:

Everybody liked the ‘kiosk’ mode (the automatically advancing slides with subtitles as the video played), but people getting to the pages for the first time had trouble realizing that the mode existed and then had trouble finding how to activate it. We tried different wordings for the button, but then, on the advise of the ‘visual’ people, just made kiosk mode the default. There was still a button, but it served now to exit from kiosk mode.

However, that led to complaints, because people relying on assistive technology now found themselves on a page that appeared to be incomplete, with only one slide and no transcript. They had trouble understanding that the button would reveal the other slides and the transcript.

So, in the end, we went back to the transcript mode as the default, with a button to enter kiosk mode. We also added a help page with a longer explanation of the button and we made it so that, if people clicked the link to the next talk while in kiosk mode, that next talk would start in kiosk mode.

What also helped was to make sure the video was always below the button that started kiosk mode. At first, the video was a fixed element on the page. It didn’t scroll with the page and was visible all the time. But then we made it a ‘sticky’ element instead (with the CSS property ‘position: sticky’) and it was only visible while the slides and the transcript were also visible. People thus had to scroll down to see the video and saw the button before they saw the video.

It seems most people in the end found the kiosk mode, though we will try different labels for the button again next time.

Slide template

For every AC meeting, we prepare slide templates with the specific style for that meeting. In the past we often provided them in different formats: HTML, of course, but also Powerpoint and Keynote. This time we only made HTML, which allowed the slides to be easily integrated into the video pages.

The few speakers who didn’t feel comfortable with HTML provided the text of their slides in some other format and team members converted it to HTML.

Our recent slides rely on the Shower script (or the b6+ script, which can work with the same format) during presentations. That script requires slides to be elements with a class attribute of ‘slide’, and elements on a slide that are displayed incrementally to have a class of ‘next’. The process that built the video pages looked for that markup to split up the slides, insert the video transcripts in the right places, and synchronize the slides with the video.

The process also relied on the fact that the slide style makes slides that have a fixed aspect ratio of 16:9. That allowed to visually align the slides and the video (also 16:9) and scale them for different screen sizes.

We will likely use the Shower slide format again for the next AC meeting and only replace the style sheet. But some investigations are underway to see if the process can be extended to accept other slide formats, even non-HTML formats.

Screenshot

Screenshot of a video page for the ML workshop with slides in PDF. Dominique succeeded in embedding a PDF viewer. It currently requires a very recent browser.

 

Standalone slides – an oversight

Originally, it was foreseen that the agenda of the meeting would have links not only to the video pages, but also to the standalone slides, so people could view them without the video (and possibly use them elsewhere in a presentation). However, the agenda ended up with just one such link, because we forgot to add the others.

As some people asked for links to the slides, we will make sure they are there for the next meeting.

CSS challenges

The video pages use the same style sheet as other AC and TPAC web pages (the ‘TPAC style’). That style determines the look of the heading, links, menus, etc. But the pages also include slides, which have their own style sheet (the ‘slide style’). Combining both on the same page obviously leads to conflicts.

Luckily, each slide is an element with a class attribute containing ‘slide’ and most style rules for slides already had ‘.slide’ in the CSS selector. Adding ‘.slide’ to the rules that didn’t removed all style conflicts for elements outside the slides.

But some style rules of the TPAC style affected the slides. To remove those conflicts, some rules had to be added to the slide style to undo the effect of the TPAC style. Luckily, there were only a few of those.

Some of the presenters needed extra style rules for their slides. We asked them to put those rules inside a <style> element at the top of their slides file, so it was easy for the program that built the video pages to copy them. To make sure those rules only affected the slides and not any other elements on the video pages, the program parsed the style rules (in a rudimentary way) and prefixed them with an ID selector.

The discussion sessions

A typical AC meeting has presentations interleaved with discussions and a final discussion session at the end to round up the meeting. And, of course, it has coffee breaks, lunches, a dinner and pre-dinner drinks.

In this case the presentations were available on video a week before the meeting itself and the meeting consisted of discussion sessions in two 90-minute teleconferences. We also opened the teleconference early (half an hour) for people to chat informally and test their video, and left it open for more informal chat after the meeting. That doesn’t replace the informal interaction at a meeting, but it helps.

It seems the participants did indeed watch all or most of the videos before the meeting. They also rated them highly. They liked the live discussion sessions as well and rated them almost as highly.

Some people reported that they skipped a few of the videos, but read the transcripts instead.

We had more participants than for physical meetings in the past, some 30%. But not as much as we hoped, given that we tried to make participation easy and cheap (no travel!).

There were also fewer questions than usual. The discussions ended by themselves slightly before the end of each 90-minute session. Maybe being able to study the presentations ahead of time removes the need for some questions. Maybe being at home watching a video removes the peer pressure of seeing people around you getting up to ask questions. We did try to make it as easy as possible to queue a question, either via the in-video chat or via IRC.

Improvements in version two

The next AC meeting will be in the fall and it will again be a ‘virtual’ one. That means we have a chance to do a ‘version 2’. There will again be prerecorded videos instead of plenary talks and discussion sessions via video-conferencing.

The sections above mentioned some ways in which we could improve the video pages and the development process. We heard other suggested improvements, including the following:

The kiosk mode (automatically advancing slides as the video plays) requires JavaScript, but the default mode (static slides and transcript, with the video on the side) could be fully functional without. That requires, however, an HTML5 <video> element with a ‘controls’ attribute rather than a video player completely controlled by JavaScript, as we used in version 1. The extra buttons that are only used in kiosk mode (advance a slide, start over, etc.) do not need to be in the static page, as they can be added by the script.

The kiosk mode could be much leaner and only show the current slide, the video, the buttons to navigate the slides, buttons to jump to the next/previous talk and a button to exit kiosk mode. It could omit the page header, footer and other elements usually found on web pages, and especially the scroll bar.

In kiosk mode, the slides and the video could use the full width of the window, even if that makes the slides and the video bigger than their natural size. That allows watching the talk on a big TV screen while sitting at a distance. (One simple way to do that would be to increase the font size of the page to something like 1.15vw through CSS.).

We again want to put captions and translated subtitles under the slides. But if we can use an HTML5 video element in the page itself, rather than a video player in an iframe on a different domain, the script in the page could use the captions in the <track> elements. Without the need to load and parse the WebVTT files twice loading would be faster. Less code probably also means fewer bugs.

In version 1, when the video is playing, the number of the current slide is indicated under the video and you can click on it to jump to the corresponding slide and transcript. It would also be nice, when reading the transcript, to be able to (re)start the video at the precise position of the slide and transcript you are currently reading. A simple button below the slide could do that. (This idea is due to Ralph Swick.)

The talks are typically short (around 15 minutes) and don’t have many slides. But, for the longer ones, especially those that treat two or more distinct subjects, a table of contents at the top might be useful.

An improvement could also be to use an <audio> element for audio-only talks, instead of a video with a static image. An audio file is probably not significantly smaller than a video file with a single static image, but using <audio> avoids showing an image that contributes no information.

With more time to prepare, we should also be able to publish the videos two weeks before the meeting, instead of one.

For the discussion sessions, we had live interpreters for three languages. However, it might be feasible to have live subtitles in those languages instead. People would then be able to still hear the speakers and their tone of voice. (This idea was proposed by Naomi Yoshizawa.)

Source code

The code we used to make the video pages is available on GitHub. It is a mix of PHP and JavaScript. The PHP code is slightly simplified from our original: We removed the links to most of the videos (many of which aren’t public) and removed the header and footer elements from the generated HTML pages to make the code shorter. (The header and footer contained links to other pages on our site and are not specific to the video pages.)

After the meeting ended we ‘froze’ the pages. I.e., the pages that were previously generated on the fly by the PHP code are now static HTML pages.

Minutes Math Telecon 2020-09-10

Source: CSS WG BlogDael Jackson • 11 September 2020

Full Meeting Minutes

Minutes Telecon 2020-09-09

Source: CSS WG BlogDael Jackson • 09 September 2020

Full Meeting Minutes

Release Notes for Safari Technology Preview 113

Source: Surfin' Safari 09 September 2020

Safari Technology Preview Release 113 is now available for download for macOS Big Sur and macOS Catalina. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS.

This release covers WebKit revisions 265179-265893.

Web Inspector

Web Audio

WebRTC

Rendering

Media

CSS

WebDriver

Accessibility

Loading

Web API

Gamepad API

Translation

Updated Working Draft: Worklets Level 1.

Source: W3C's Cascading Style Sheets home page08 September 2020

8 Sep 2020 Updated Working Draft: Worklets Level 1.

Minutes Telecon 2020-09-02

Source: CSS WG BlogDael Jackson • 03 September 2020

Full Meeting Minutes

Thanks to Fastly, our CDN partner for Code://Remote

Source: Web Directions Blog John • 28 August 2020

When I first started developing for the web it was a pretty straightforward task. Sure we were still trying to work out how best to use HTML (then CSS, and later JavaScript) but we really didn’t worry much about builds, integration and deployment (editing in production was very much thing), let alone something as complex as Content Delivery Networks.

It does sound very quaint now I know.

But as we looked to deliver our conferences online, we knew content delivery was going to be vital. With hundred or more people logging in and streaming the conference, people located all across the world, and wanting to ensure they all got that content, that we were going to a lot of trouble and expense to shoot at 4K, as high quality as possible and as near to simultaneously as possible to recreate the shared experience of in-person events our CDN was going to be as important a piece of the technology puzzle as anything else.

One way I have long assessed technology companies is by the sort of people they employ. Great companies can identify great people, and also attract and maintain them.

One reason we knew Fastly was precisely because they had attracted people I really admire in the industry. Folks like Patrick Hamann, Andrew Betts, and Mark Nottingham, all of whom have made significant, indeed huge contributions to the Web and the development of standards, practices and technologies we all use every day.

So when it turned out our hosting company Platform.sh, and streaming provider both relied on Fastly for content delivery I feel it was more than a lucky circumstance.

As we head into the home straight of delivering our first online conference, we’re breathing a little easier knowing Fastly is there getting you the content.

See two dozen world-leading experts on all things JavaScript and front end development at Code://Remote September 2020

Code://Remote takes place across the month of September, and features two dozen world-leading experts on all things JavaScript and front end development at an amazing price, just $295 before August 28th.

Learn more and register now

Conveniently timed for attendees from the North American West Coast, right across the pacific to Hong Kong and Singapore, Japan and beyond connect–with your peers at Code.

The post Thanks to Fastly, our CDN partner for Code://Remote appeared first on Web Directions.

Updated Working Draft: CSS Inline Layout Level 3.

Source: W3C's Cascading Style Sheets home page27 August 2020

27 Aug 2020 Updated Working Draft: CSS Inline Layout Level 3.

Minutes Telecon 2020-08-26

Source: CSS WG BlogDael Jackson • 26 August 2020

Full Meeting Minutes

CSS Cascading and Inheritance Level 4 Returned to WD

Source: CSS WG Blogfantasai • 20 August 2020

The CSS Working Group is returning CSS Cascading and Inheritance Level 4 to Working Draft status in order to incorporate the cascading and inheritance rules pertaining to Shadow DOM. Also to drop scoped styles (again) due to lack of interest from implementers. (An update to CSS Cascading and Inheritance Level 3 has also been published to keep editorial fixes in sync.)

CSS Cascading and Inheritance describes how to collate style rules and assign values to all properties on all elements by way of cascading (choosing a winning declaration among many) and inheritance (propagating values from parent to child). Changes since the previous Candidate Recommendation are listed in the Changes section.

This is a Last Call for Comments; the CSSWG expects to return the module to CR soon. We are requesting comments, or alternately a request for extended time, by 20 September 2020.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-cascade-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

CSS Grid Layout Level 2 (Subgrid) Candidate Recommendation

Source: CSS WG Blogfantasai • 20 August 2020

The CSS Working Group has published a Candidate Recommendation and invites implementations of CSS CSS Grid Layout Level 2. This module defines a layout manager, the grid, which makes it easy to specify complex, responsive 2-dimensional layouts for a page or sub-component of the page. Level 2 introduces the “subgrid” feature that was cut from Level 1 due to lack of implementations, and which allows sharing grid lines across nested markup.

There have been no changes since the previous Working Draft other than incorporating the full text of CSS Grid Layout Level 1; and all new features other than subgrid have been deferred to Level 3.

The editors are grateful to Mozilla for implementing and giving feedback, and encourage other CSS implementations to update so that authors and users can benefit from subgrid’s ability to combine content-sized grid layouts with nested structural markup.

Feedback can be sent by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-grid-2]) and your comment topic in the subject line.

CSS Grid Layout Level 1 Revision 3

Source: CSS WG Blogfantasai • 20 August 2020

The CSS Working Group has published an updated Candidate Recommendation of CSS Grid Layout Level 1. This module defines a new type of layout manager, the grid, which makes it extremely easy to specify complex, responsive 2-dimensional layouts for a page or sub-component of the page.

This update addresses most of the feedback received since the December 2017 CR, including almost all of the known errors; there remain a number of issues relating to improvements to track sizing algorithm that will be addressed in the next revision. The changes consist mostly of slight adjustments to the grid sizing algorithm and a few fixes to things like serialization. All significant since the last Working Draft are listed (with diffs) in the Changes section, and a Disposition of Comments (102 issues) is available.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-grid-1]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Minutes Telecon 2020-08-19

Source: CSS WG BlogDael Jackson • 19 August 2020

Full Meeting Minutes

Release Notes for Safari Technology Preview 111

Source: Surfin' Safari 18 August 2020

Safari Technology Preview Release 111 is now available for download for macOS Big Sur and macOS Catalina. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS.

This release covers WebKit revisions 263988-264601.

Web Inspector

Web Extensions

Scrolling

Rendering

CSS

JavaScript

Web Authentication

WebRTC

Web API

Storage Access API

Intelligent Tracking Prevention

Accessibility

Text Manipulation

Release Notes for Safari Technology Preview 112

Source: Surfin' Safari 18 August 2020

Safari Technology Preview Release 112 is now available for download for macOS Big Sur and macOS Catalina. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS.

This release covers WebKit revisions 264601-265179.

Web Inspector

Extensions

CSS

JavaScript

SVG

Media

WebRTC

Web API

Text Manipulation

Storage

Updated Candidate Recommendation: CSS Grid Layout Level 1. N…

Source: W3C's Cascading Style Sheets home page18 August 2020

18 Aug 2020 Updated Candidate Recommendation: CSS Grid Layout Level 1. New Candidate Recommendation: CSS Grid Layout Level 2. Updated Working Draft: CSS Cascading and Inheritance Level 4.

Updated Candidate Recommendation: CSS Cascading and Inherita…

Source: W3C's Cascading Style Sheets home page17 August 2020

17 Aug 2020 Updated Candidate Recommendation: CSS Cascading and Inheritance Level 3.

Minutes Telecon 2020-08-12

Source: CSS WG BlogDael Jackson • 13 August 2020

Full Meeting Minutes

Minutes Telecon 2020-08-05

Source: CSS WG BlogDael Jackson • 06 August 2020

Full Meeting Minutes

Style Stage is a project by Stephanie Eckles (5t3ph on Twitt…

Source: W3C's Cascading Style Sheets home page04 August 2020

4 Aug 2020 Style Stage is a project by Stephanie Eckles (5t3ph on Twitter) to showcase CSS. It invites designers to style the same page in their own way. It was inspired by Dave Shea's CSS Zen Garden.

Updated Working Draft: Media Queries Level 5.

Source: W3C's Cascading Style Sheets home page31 July 2020

31 Jul 2020 Updated Working Draft: Media Queries Level 5.

Happy Birthday Web Fonts!

Source: W3C BlogVladimir Levantovsky • 27 July 2020

A graph showing web font usage since 2011

Adoption of web fonts by major websites (Data source: HTTP Archive)

Mondays are dreadful, right? So much so that it inspires people to search for “How do I get motivated on Monday?”, which is what Google says is a popular search topic when I typed ”Monday” in the search box … But not today – July 27, 2020 is a very special Monday: the one that marks the 10th anniversary of the event that changed the way we see and read text on the Web; it changed the way how brands communicated with their customers worldwide; it literally changed the face of the Web! (typographic face, i.e.)

Ten short years ago, the newly formed WebFonts Working Group published a First Public Working Draft of Web Open Font Format, and many (virtually all) browser vendors introduced new versions that supported it shortly thereafter. By doing so, they offered web developers an exciting new technology to experiment with, provided new tools to make their websites stand out from the rest, to make them look authentic, more readable, and user-friendly!

Initially seen by some as a niche technology to spruce up headlines, web fonts took the Web by the storm. By the time the WOFF 1.0 Recommendation was finalized, the web fonts adoption rates have surpassed WebFonts Working Group’s wildest expectations of 10% adoption, raising bandwidth consumption to the levels that made us clearly realize that the dedicated font data compression is a necessity. The new and improved WOFF 2.0 development was launched as a result, and the Web as we used to know it, is now a “recent” past – using web fonts is now mainstream, and the WOFF 2.0 (finalized in March 2018) made web fonts third widely adopted Web technology (after HTML and CSS). (Notably, both WOFF 1.0 and WOFF 2.0 are based on the ISO/IEC 14496-22 “Open Font Format” standard, which by 2009 was widely supported in virtually all consumer electronic devices, paving the way for WOFF technology adoption at unprecedented scale!)

The WebFonts Working Group is currently developing a new mechanism for progressive font downloads with the goal of optimizing font data delivery and making web fonts faster to load and user friendly. This recent analysis of web fonts usage by country shows that the median number of bytes of web fonts used for pages in China is *zero*! Clearly, more work is needed to makes web fonts attractive for all world languages.

Happy 10th Anniversary Web Fonts!

#W3C, #woff, #webfonts, #webtechnology, #MondayMotivation

the Web at a crossroads

Source: Web Directions BlogJohn • 27 July 2020

blockquote {margin-left: 2em; font-size: .9em; border-left: solid thick #999; padding-left: .5em}

To say the Web’s origins were humble would be an understatement.

Considered by hypertext experts at its beginning to be markedly inferior to the then state of the art, its ambitions were in many ways limited. A way to view documents, and link them together, it supported a small number of elements for structuring these documents (a few levels of heading, paragraphs, lists, and not much else) at a time when desktop publishing was making the use of fonts, images, colour, layout straightforward, even simple. The web meanwhile had none on these.

But nevertheless the Web prevailed. Why exactly is the topic of discussion for another day. Over the ensuing decade the web gained images (not entirely to the satisfaction of its inventor), the ability to style text in numerous ways, to use initially the fonts available on a user’s system, then embedded fonts (all this in the 1990s, long before the likes of Typekit), and sophisticated layout.

By the late 1990s, we were thinking of the Web as a fully fledged publication system (often tying ourselves into knots trying to smooth out the ways it differed, quite intentionally, from WYSIWYG desktop publishing).

Along the way too it gained JavaScript and, by today’s standards, a primitive DOM, but the use of these features was limited, to things like form validation (and usually very little else).

The idea of the Web as a platform for applications that might replace the desktop computer and operating systems like Windows and Mac OS might have been the dream of at least some of us working on the Web in the late 1990s, but in truth more a pipe dream.

Fast forward to 2020, and that pipedream is a reality. On the desktop (by which I also, of course, mean the laptop) the web is the primary way by which people interact–users spend on average more time using a browser than all other apps combined on their desktop devices.

After all does anyone use a Facebook or Netflix app on their Windows or Mac computer?

On the desktop, the Web won

And yet the Web currently faces a crisis of relevance. Because the desktop is a legacy and niche platform now. And when it comes to mobile and tablet platforms that dominate computing today, the platform technologies developers have access to, the ones that matter and really make the mobile experience completely different from the desktop–device sensors and capabilities, cameras, microphones, magnetometers, geolocation, Bluetooth, NFC–are all extremely limited or simply unavailable.

Does this matter? After all, the Web did fine on the desktop even when it has never had some of the key technologies available to native desktop apps–like access to the filesystem?

Recently Alex Russell, who in myriad ways, including coining the term and fleshing out many of the concepts underpinning “Progressive Web Apps”, helping develop standards at the W3C and JavaScript at TC39, among many others observed

the web thrives or declines to the extent it can accomplish the lion’s share of the things we expect most computers to do

Platform Adjacency Theory

On the desktop, even with limited access to the file system, by the mid 2000s, as pioneered by the likes of Gmail and Google Maps, the web could “accomplish the lion’s share of the things we expect most computers to do”.

But it can’t today. What we expect computers to do has changed.

Alex’s article was prompted in part by recent communications from the people involved in Apple’s WebKit project, as well as Marcos Caceres at Mozilla, himself a significant long-term contributor to the development of Web standards at the W3C, that due to (it must be acknowledged very real and genuine) concerns about the impact on user privacy and security, these browsers (Safari and Firefox) will not (yet) implement a raft of platform capabilities for Web developers to access, including (among others) Bluetooth, NFC, Ambient Light sensors, background geolocation, and proximity sensors.

There have been some, if not exactly heated, then let’s say uncomfortable conversations in recent weeks with push back by developers like Maximiliano Firtman, who has called this decision ‘lazy’.

It so happens I personally know Alex, Marcos and Maximiliano, the first two very well, as well as folks from the Webkit team at Apple. I genuinely believe all have the best interests of the Web at heart. I really don’t have any truck with suggestions that decisions are made at the level of browser feature implementation for overall corporate strategic reasons (for example to reduce the capability of a web browser to ensure the primacy of native apps on a platform. Your opinion may differ, but I simply don’t find this all that useful to speculate about).

But that’s not to say these decisions don’t have significant impact on the prospects for the Web, and as the title of this article makes clear, I think this is a pivotal time in the history of the evolution of the Web. I think too this is why these conversations have become a little strained. Will the Web continue to evolve, and keep up with the evolution of the underlying platforms, or will it essentially become a legacy way of developing for the desktop, and viewing content on mobile?

Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.

Alex Russell speaks to this issue with far greater complexity and depth in Platform Adjacency Theory, and I very much recommend you read this if it’s of interest to you.

While this issue came to a head in recent weeks around Apple’s World Wide Developer Conference, it so happens months ago we programmed our upcoming Code://Remote conference to open with Marcos Caceres and Kenneth Rohde Christiansen (currently a software engineer at Intel who’s worked for years on browser platforms, including at Nokia at the dawn of the mobile Web), who like Alex and Marcos has contributed significantly to the development of the Web (all three are or were members of the W3C’s Technical Architecture Group, an elected group at the W3C “responsible for stewardship of the Web architecture”.)

Kenneth is a driving force behind Project Fugu, “an effort to close gaps in the web’s capabilities enabling new classes of applications to run on the web”.

At Code://Remote Kenneth will be providing a detailed overview of Project Fugu, then Marcos will address in some depth the thinking behind limiting these capabilities, as well as share ways in which the underlying platform capabilities can be exposed to Web developers without compromising the privacy and security of users.

A Challenge and Opportunity for the Web

I do feel this is a crossroads for the Web. These are genuinely challenging issues. But I also feel it represents a huge opportunity for the Web as a platform.

Native Apps, available through a platform’s App Store, once promised to safeguard the user’s privacy and security, but numerous breaches, not simply by shady developers flying under the radar, but by some of the most widely used apps in the world, have exposed the fragility of the security-though-platform-gatekeeping approach.

The Web’s approach, of baking security and privacy protection into the platform itself (one simple example is only giving access to new device APIs over HTTPS connections) is a hands down a better strategy.

But the platform can’t be left to languish, which given WebKit’s browser engine monopoly on iOS, and the WebKit team’s reticence to implement access to many device capabilities, there is a very real danger of.

Discuss and learn more at Code://Remote

We’re fortunate to have several of the people at the forefront of this issue speaking at Code://Remote, one that may well determine how relevant the Web will continue to be in the coming decade.

In the late 1990s and early 2000 the idea that the Web would become the dominant platform for desktop computing seemed unlikely, just as the idea that it may become the dominant platform for mobile computing is today. And yet it happened. Will history repeat?

See two dozen world-leading experts on all things JavaScript and front end development at Code://Remote September 2020

Code://Remote takes place across the month of September, and features two dozen world-leading experts on all things JavaScript and front end development at an amazing price, just $295 before August 28th.

Learn more and register now

Conveniently timed for attendees from the North American West Coast, right across the pacific to Hong Kong and Singapore, Japan and beyond connect–with your peers at Code.

The post the Web at a crossroads appeared first on Web Directions.

Minutes Telecon 2020-07-22

Source: CSS WG BlogDael Jackson • 22 July 2020

Full Meeting Minutes

Updated CR of Media Queries L4 and WD of Media Queries L5

Source: CSS WG Blog Florian Rivoal • 22 July 2020

The CSS WG has published an updated Candidate Recommendation and invites implementations of Media Queries Level 4. It has also published an updated Working Draft of Media Queries Level 5.

Media Queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and JavaScript.

Level 4 brings significant improvements to the syntax, and refocuses Media Queries away from categorizing devices into exclusive media types, and instead introduces a broad range of media features, to enable authors to inquire about various aspects of the environment the web page is being rendered into. This include the viewport’s geometry, information about the color capabilities, the input devices, and a few more things.

This new Candidate Recommendation is a fairly minor update from the previous one. The main changes are documented in the Changes section. A Disposition of Comments is available.

Level 4 is considered fairly stable at this point, with no known issue. The CSS Working Group encourage User Agents to continue implementing it, and is looking for feedback from these implementers and early users of its features.

Level 5 builds upon this foundation, adding a few more media features to look into things like the dynamic range of the display, whether the rendering environment is capable of running scripts, or whether the content is rendered on an opaque or transparent screen. It also explores a few new areas:

Details of changes since the previous Working Drafts, as well as between level 4 and 5 are listed in the Changes section.

The features introduced Level 5 are much more experimental, and the CSS Working Group encourages broad discussion of their benefits and downsides. Participation in the discussion of existing unresolved issues is most welcome.

Please send feedback on either documents by filing an issue in GitHub, including [mediaqueries-4] or [mediaqueries-5] in the title of the issue as appropriate.

Alternatively, you may also send a mail to the (archived) public mailing list www-style@w3.org with the spec code ([mediaqueries-4] or [mediaqueries-4]) and your comment topic in the subject line.

Updated Candidate Recommendation: Media Queries Level 4.

Source: W3C's Cascading Style Sheets home page21 July 2020

21 Jul 2020 Updated Candidate Recommendation: Media Queries Level 4.

Release Notes for Safari Technology Preview 110

Source: Surfin' Safari 16 July 2020

Safari Technology Preview Release 110 is now available for download for macOS Big Sur and macOS Catalina. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS.

This release covers WebKit revisions 263214-263988.

WebRTC

Web Authentication

Web Animations

Web API

Media

CSS

Layout

Rendering

Accessibility

Bug Fixes

JavaScript

Storage Access API

Text Manipulation

Security

Web Inspector

Minutes Telecon 2020-07-15

Source: CSS WG BlogDael Jackson • 15 July 2020

Full Meeting Minutes

Feeds

The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

fantasai

Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed