Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[WIP] add forwards compatibility / graceful degradation principle. #468

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

[WIP] add forwards compatibility / graceful degradation principle. #468

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
74ba438
Import 'Degrade Gracefully' from the HTML Design Principles document.
hober Jan 24, 2024
cfd1630
work in progress
hober Jul 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
115 changes: 115 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -294,6 +294,7 @@ Parts of the web platform evolve independently.
Issues that are present with a certain web technology now may be fixed in a subsequent iteration.
Duplicating these issues makes fixing them more difficult.
By adhering to this principle we can make sure overall platform quality improves over time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vertical whitespace is useful. Why would you remove the space around the h2?

(A more serious problem here is the lack of content between the h2 and the first h3. That's very bad form.

<h2 id="api-across-languages">API Design Across Languages</h2>

<h3 id="simplicity">Prefer simple solutions</h3>
Expand Down Expand Up @@ -490,6 +491,120 @@ See also:
* [[#do-not-expose-use-of-assistive-tech]]
* [[#secure-context]]

<h3 id=degrade-gracefully>Degrade Gracefully</h3>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<h3 id=degrade-gracefully>Degrade Gracefully</h3>
<h3 id=degrade-gracefully>Degrade gracefully</h3>

<!-- was "Degrade Gracefully" in the HTML Design Principles -->

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TL:DR; summary please!

Authors are (understandably) reluctant to use
new Web-exposed features
that may trigger undesirable behavior in older user agents,
or that do not provide some sort of graceful fallback.
Web-facing features should be designed
so that Web content can degrade gracefully
in older or less capable user agents,
even when sites make use of the new features.

It is not necessary
to consider every Web user agent ever made,
including even very old versions of browsers
or tools that are extremely unpopular even in their niche markets.
However,
strong consideration should be given
to the following categories of user agents.
It is highly likely
that content authors will find it important
to target these categories:

* Current versions of the top mainstream Web browsers.
* Highly popular older versions of mainstream Web browsers.
* The top user agents
designed to meet specific needs or address specialized markets,
such as assistive technologies or user agents targeting less typical media
such as text-only terminals or print.

In some cases,
a new feature may simply not apply
to a certain class of user agents,
or may be impractical to design
in a way that can degrade.
For example,
new scripting APIs
cannot be made to work
in scriptless user agents.
But in many cases,
approaches like the following
can be used:

* A new element or attribute
may provide additional semantics
without losing essential functionality
when not understood.
* A new scripting method or attribute
can be tested before use
in script
using ECMAScript introspection facilities.
* A new element or attribute
may provide semantics
and a simple default rendering
that can be achieved using CSS,
so the addition of a small stylesheet
allows graceful degradation.
* A new element, attribute or scripting API
may have behavior
that can be emulated
through the use of additional script,
although the scripted approach
may not provide
the same level of performance and convenience.
* A new element
may call for
a highly specialized rendering,
but allow different content to be provided as fallback
for user agents that do not understand the element.

This list is not exhaustive;
in some cases
slightly more complicated approaches
are more effective.

<p class="example">The default presentation
of the <code>hidden</code> attribute
can be emulated
in older browsers
through the CSS rule <code>[hidden] { display: none; }</code>.

<p class="example">Multimedia elements
like <code>&lt;canvas&gt;</code> or <code>&lt;video&gt;</code>
allow fallback content.
Older user agents
will show
the fallback content
while user agents supporting these elements
will show
the multimedia content.

<p class="example">The <code>getElementsByClassName()</code> method
can be made
considerably faster than
pure ECMAScript implementations
found in existing libraries,
but a script-based implementation
can be used
when the native version
is not available.

<p class="example">The <code>&lt;datalist&gt;</code> element
can be associated
with an <code>&lt;input&gt;</code> element
and may contain
a hidden <code>&lt;select&gt;</code> element.
This way
the fallback
for the intended "combo box" control
can be
a text field
or a text field with an associated pop-up menu
in older browsers.

<h3 id="secure-context">Consider limiting new features to secure contexts</h3>

Always limit your feature to secure contexts
Expand Down