- From: Sean Hogan <shogun70@gmail.com>
- Date: Fri, 10 Apr 2015 02:17:27 +1000
- To: "public-html@w3.org" <public-html@w3.org>
What would framesets be like if we designed them today?
======================
Where would they be used?
-----------------------
Framesets (or emulations of framesets using a master-page and iframes)
are still in broad use, especially amongst documentation generators.
- Javadoc e.g. https://docs.oracle.com/javase/8/docs/api/
- Adobe Robohelp e.g. http://www.grainge.org/pages/authoring/rh_tour/index.htm
- MadCap Flare e.g.
http://webhelp.madcapsoftware.com/flare10NonResponsive/Default.htm
- Help-and-Manual e.g. http://www.helpandmanual.com/help/
- Innovasys Help Studio e.g. www.innovasys.com/help/hs/webframe.html
- HelpNDoc e.g.
http://www.helpndoc.com/sites/default/files/documentation/html/index.html
- WebWorker ePublisher e.g. http://www.webworks.com/Documentation/Reverb/
- FastHelp e.g. http://www.fast-help.com/WebsiteHelp/index.html?v8200
- HelpGenerator e.g. http://www.helpgenerator.com/help/help.htm
- Helpinator e.g. http://www.helpinator.com/webhelp/index.html
IIRC, none of these keep the address-bar URL matched to the primary content.
(Some of them use fragile work-arounds such as manual & automatic
redirects to the frameset page URL and/or the primary content URL
encoded into the frameset URL's query or hash).
Framesets designed today *should* be usable by these documentation
generators with minimal changes and *must* handle keeping the
address-bar URL matched to the primary-content automatically.
There are many other site generators that create similar sets of content -
many content pages, T.O.C., indexes, etc -
but don't present them in a frameset.
These generators should be able to use redesigned framesets with
minimal changes.
Ideally, even the content-author using such a generator should be able
to take the output files and make minimal changes to make use of
redesigned framesets.
Maybe even the end-user could have the power to apply a customized
frameset to such a site.
The preceding types of sites all seem to match the classical usage of framesets.
But if we were redesigning framesets maybe there will be all manner of
sites that are amenable to the approach.
In the introductory video - https://youtu.be/qVdAc8_ppao (skip to
22:40) - I demonstrate how twitter.com might be implemented as a
highly evolved frameset applied to (the much simpler yet
fully-functional) mobile.twitter.com.
Between traditional frameset sites and examples such as twitter.com
lies a significant proportion of the web (including almost every site
that uses jquery-pjax - https://github.com/defunkt/jquery-pjax).
The only precondition for this type of application would be that the
site is fully-functional without Javascript *and* without redesigned
framesets.
What are the required changes?
-------------------------
### Content First
HTML Frameset sites require the end-user to navigate to the
frameset-page which then loads primary and auxiliary content.
This needs to be the other way around - when the end-user first lands
on a site the primary-content of the landing-page should load first
and only then (and perhaps conditionally) the appropriate frameset is
applied. Later navigation around the site would be managed by the
"frameset", naturally updating the URL in the address-bar.
### Flexible layout
The original frameset implementation used the <frameset> element for layout.
Some sites emulate framesets with a master-page containing <iframe>s
to give better layout flexibility.
A redesigned frameset implementation must follow this latter example.
### Content shouldn't be designed for the frameset
Framed content in HTML Frameset sites is often designed specifically
for the frameset. This imposes restrictions on layout, styles,
contextual content, etc which may conflict with how the content might
be presented if it were a stand-alone page.
This needs to be switched - content pages should be designed for the
stand-alone scenario and the frameset implementation must be capable
of manipulating that content into the representation it needs.
This has two implications:
- Frame transformations: a frame must be capable of modifying the
(stand-alone) content it receives before rendering.
- Lightweight frames: styles and dynamic behavior for the framed
content must be set by the frameset
These in turn imply that scripts in the framed document cannot be
executed - this is not an issue since one of the meta-goals of a
frameset redesign is that pages / sites are fully-functional without
scripting.
### Hyperlink targetting is determined by the frameset, not the content
This is actually another implication of the previous requirement.
Since the content should not be aware of the frameset, hyperlinks in
the content cannot have a predefined target. Hyperlink targetting must
be determined from the frameset.
### Adaptive / responsive design
- The frameset should adapt to the available space in the browser.
- The frameset must have the ability to adapt to different categories
of content being displayed
- Sometimes these adaptations may result in parts of the DOM being
hidden (or even never displayed).
If a frame is enclosed by a hidden DOM tree then its content probably
should not be downloaded.
In general auxiliary content should be lazy-loaded.
A partial design
-----------------
### Determining the frameset for a URL
The end-user navigates to a URL. The page content begins to download.
How does the browser determine the appropriate frameset?
1. <link rel="frameset" href="..." />
Optionally these links could make use of @media but preferably this is
handled by the frameset.
This setting can be over-ridden by...
2. Scripted
Hard-coding the frameset on the server - using <link rel="frameset"> -
conflicts somewhat with the idea of decoupling the content from the
frameset. There should be the option of deferring this decision to a
script that can run on the client.
3. User configuration
This potentially allows the end-user to choose an alternate /
customized frameset for the site.
The site could provide alternate framesets or the user could
potentially design there own.
While this latter scenario is unlikely to be of general use (unless
web-sites adopt common application-level semantics) it would allow a
site-developer to privately test a new frameset on a live site.
The most likely user configuration option is to just disable framesets.
### Frameset definition
Theoretically the frameset could be defined in various ways, but there
are several advantages to using a stand-alone HTML document (with a
few frameset only custom-elements).
- the rendered frameset will be a HTML DOM
- more likely that editors and linters can be modified to understand
custom-HTML than custom-HTML-in-Javascript-strings or other
DOM-generation code
- the frameset can be viewed in a browser - visual verification can be
one of the quickest ways to spot errors
- HTML framesets had a frameset document so conceptual understanding
is facilitated
NOTE: The frameset document is not navigated to directly nor is it
directly rendered. This allows it to break some of the rules of normal
page loads which in turn enables more complex behavior than HTML
framesets. For example, script-handling can be different.
Applying a frameset definition means *replacing* the current browsing
context with a new one *based on* the frameset definition (but
retaining the landing-page URL). Polyfills will need to emulate this
process (and hope for the best).
### Frame definitions
Inside of the browser view (equivalent to the *rendered* frameset) a
frame is the point where content from a different URL is inserted.
But the content may need to be transformed first, and the frame also
needs to handle different states of content readiness - uninitialized,
loading, error, loaded.
Inside the frameset definition a frame defines this transformation and
ready-state handling.
Ideally this could be done with markup. The following is a suggestion:
<hf-frame id="unique-defn-id" main=".css .selector">
<!-- a frame *definition* can have multiple bodies -->
<hf-body condition=" uninitialized | loading | error | loaded">
<hf-transform type=" main | script | xslt | custom " format="
css | xpath | microdata | microformats | custom ">
<!-- content of the transform matches the @type and defines how to
process a fetched document into a form appropariate to
be rendered. -->
</hf-transform>
<hf-transform type="main">
<!-- transforms can be chained. -->
</hf-transform>
</hf-body>
</hf-frame>
When a *frameset definition* is loaded and parsed, each frame
definition is replaced with a frame declaration.
If the frame definition has no identifier then one is auto-generated.
The frame declaration receives a frame definition reference which
points to the frame definition.
The frame definition is added to a set of definitions indexed by @id.
After this processing the <body> of the frameset definition will
contain one or more frame declarations and each frame definition will
contain zero or more frame declarations.
Suggested transform types include:
- `main` which extracts the contents of the source documents <main> or
@role="main" or <body> or some custom selector
- `script` which processes the source document via javascript
- some form of advanced declarative transforming / templating language
### Frame declarations
Inside the frameset definition a frame declaration looks like a frame
definition without any content.
It would mimic the original <frame> signature like so:
<hf-frame def="unique-defn-id" src="/some/path"
name="not-necessarily-unique-name"></hf-frame>
The @def references a frame definitions. Several frame declarations
can share the same definition.
Frame declarations first enter the browser view when the frameset
definition's <body> is inserted.
When a frame declaration enters the browser view, its @src is fetched
and the contents of the frame are updated according to the resource's
ready-state and the frame's frame definition (referenced by @def).
Considering the case of the resource being fully loaded, it is
processed by the transforms specified in the frame definition's
`<hf-body condition="loaded">`. The output of this processing
(assuming no failure) becomes the content of the frame. This may
result in more frame-declarations entering the browser view which are
processed in turn.
### Hyperlink targetting
Hyperlink targetting is not a property of the hyperlink, since the
content should be agnostic about the frameset.
It has to be a role of the frameset itself.
When the end-user clicks on a hyperlink, the click event bubbles up
through the nearest enclosing frame, parent frames, the frameset (i.e.
the <body>) and then to the document root.
Each frame may respond to the hyperlink with a target reference. (How
this lookup can be defined declaratively is not suggested). If it does
respond then the event is prevented from bubbling.
The target reference is used to find frames in the browser view by
their @name. Each of the found frames has its @src updated to match
the hyperlink and is reprocessed similarly to if it had just entered
the browser view. Updating the content of frames can cause descendant
frames to be removed from the view and new descendant frames to enter
the view.
If no frames respond to the hyperlink then conditionally the frameset
may respond. If the frameset can specify a target then processing is
the same as for frames AND the document.URL is updated to match the
hyperlink. Obviously this cannot occur if the hyperlink is to a
different site, in which case the frameset doesn't have the option to
respond and a normal browser navigation occurs.
### Landing page
Processing of the landing page is a special case of hyperlink
targetting. The frameset responds to the document.URL (which is that
of the landing-page) with a target reference. As frame declarations
enter the view, if they have a matching @name their @src is changed to
match the document.URL and processing is done as normal.
### Nested frames
Frames can be arbitrarily nested. When this is combined with document
transformation it makes dynamically loaded hierarchical-menus and
directory-trees trivial, for example:
A directory tree is split into several files, each containing one
sub-tree. A navigation section in the frameset has a frame-declaration
that sources the top level file of the directory tree. The frame's
frame-definition specifies a transform which converts sub-tree
*hyperlinks* into *frames* which source the sub-tree and apply the
same transform as for the top level.
### Conditional content
It is possible that some sub-trees of the rendered DOM are hidden. Any
frames that are enclosed by hidden sub-trees should not be fetched and
processed until they are visible (or about to be?).
This may allow multi-views and responsive-layout to be orthogonal to
the behavior of frames.
It is envisaged that custom-elements may also be appropriate to
declare these features.
Problems
----------
- Handling non-GET <form>s at the frameset-level (i.e. document.URL
would change) needs exploration.
- How complex should state-management be?
- How to do "hyperlink targetting" declaratively but flexibly?
- It would be nice to have something like XSLT that could be parsed in
HTML (and that more people liked)
- It would be nice to have a microdata / microformats parser and path language
- Your issues here...
On Wed, Apr 1, 2015 at 4:56 PM, Sean Hogan <shogun70@gmail.com> wrote:
> HTML framesets were the original single-page-application.
>
> Despite the flaws (mostly not being content-first), at least servers
> were emitting reasonably simple HTML including real hyperlinks and
> forms.
>
> What would framesets be like if we designed them today?
>
> In the linked video I make the case for a successor to framesets.
> It is 25 minutes but that is unavoidable.
>
> https://youtu.be/qVdAc8_ppao
>
> The first half illustrates *why* this is important / better than alternatives,
> with actual demonstrations (which you should try for yourself to
> ensure I'm not cheating).
>
> The second half provides some insight into how I've approached this,
> again with demonstrations.
>
> I'll continue later with details of the differences / enhancements
> required to make the frameset concept live up to today's expectations.
>
> regards,
> Sean
Received on Thursday, 9 April 2015 16:17:56 UTC