HTML on a Prim Taxonomy

This page is to help us enumerate the different possibilities and options for "HTML on a Prim". It is here so that we are all talking the same thing, and know what we all mean by the different options.

See also: HTML on a Prim Use Cases

---

There are three main axes in this design space: Source, Rendering, Interaction:

Source

Notecard, LSL, Web

Rendering

Prim Face, Media Texture, 2D Floater

Interaction

Static, Local, Shared

Sources

HTML on a Prim can come from several possible sources. Each one having a distinct use, where some overlap may occur between classes of use.

HTML from a Notecard

HTML is rendered from a notecard contained within the prim, or a UUID reference to the notecard.

Issues

1. Images
   • Images should be referenced by UUID
   • Images must be full permission unless contained in the prim?

1. Links
   • Links would reference other notecards

-What about classic <image> tags? Also, I think when referencing by UUID or name, it should work like llSetTexture() currently does.
When referenced by actual name, the texture, no matter the perms, needs to be in the object. Referencing by key always works.
As for links, I'd suggest a SL-specific tag for referencing other notecards as well, and let vanilla HTML linking tags work as normal --Chalice Yao 05:07, 7 November 2007 (PST)

Uses

1. Books
2. Magazines
3. Catalog
4. Help Manual
5. Advertisements

HTML from scripting

HTML is rendered from the output of a script.

Issues

1. Script Memory Constraints
2. Images
   • Images should be referenced by UUID
   • Images must be full permission unless contained in the prim??
3. Links
   • Links should raise events in the scripts

Uses

1. HUDs (with images)
2. Changing Text Displays
3. Item Vendors
4. GUI Screens

This method could be combined with HTML from a notecard for forms. Would require new script events to handle form submission

HTML from the internet

HTML is rendered from an internet site

Issues

1. Plugins that can't be rendered
2. Referenced images can't be by UUID, must be on the webpage ??
3. Can't be directly tied into scripts ??
4. At what point does the browser return the the initial URL ??

Solutions to Issues

1. A URI, secondlifeasset:// , could be used to reference assets by UUID

Uses

1. Web Browsing
2. Books/comics
   1. Text on a prim
   2. PDF-like manuals
   3. Comic strips
3. Magazines
4. Shopping
   1. Vending machines
   2. Shopping carts
   3. Interface with eBay/Paypal and buy real items in-world
5. Advertisements
6. HUD Elements
7. Gui Screens
8. Text Displays
9. Images on a prim
   1. Web-based textures
   2. Share Flickr and Imagebucket photos
   3. Comic strips
10. Better interfaces for in-world systems
    1. Better in-world computers
    2. Movie screens
11. Better means of in-to-out world chatting:
    1. Can use IRC-CGI program
       1. The Chatzilla extension for Firefox could be modified to run under uBrowser
    2. Can follow Twitter feeds
    3. Can use web-based AIM, IRC, etc.

Rendering

Render to a Prim Face

Allow HTML to from source to be placed on any prim face.

Issues

1. Do all the texture operations (repeat, offset, angle, animation) apply ??
2. Can the viewer handle a large number of prim faces with browsers on 'em ??

Render to a Media Texture

Like the streaming video, HTML could replace one special texture per parcel.

Issues

1. Wouldn't this preclude HUDs?
2. A way of limiting the amount of work the viewer must do
3. Could you "play" more than one at a time? Or would the HTML textures on other parcels be blank?

Render to In-Client 2D Blowser Floater

Issues

1. Only displays help page in default client.
2. Will not render some pages properly (Flash?).

Solutions to Issues

1. Either:
   1. Add an address bar, or
   2. Implement llLaunchBrowser command in LSL.
2. Tell people to only use AJAX.

Uses

1. See: World Wide Web (http://en.wikipedia.org/wiki/World_Wide_Web)
2. See: HTML on a Prim
3. Useful for displaying help and documentation for objects in world - easiest to read, and private to user.

Interaction

No matter what the source, or where rendered, there is the issue of how users interact with these HTML pages.

Static

Simple answer: None. The HTML is basically a way to specify a rendered texture. Once rendered, the page operates just like any other texture.

Issues

1. Each viewer would do the render once

Local

Once loaded, each viewer is running its own browser in the rendered area. When one user follows links, the others don't.

Issues

1. At what point does the browser get reinitialized with a URL?

Shared

It is as if the browser is on the object in world. When anyone follows a link, everyone sees the page change.

Issues

1. With only a browser in the viewer, this could only be achieved by trying to synchronize each viewer's browser instance looking at the same prim face. This is almost certainly not a workable option except perhaps for notecard sourced HTML.

Unanswered Issues

• Caching -- does each viewer implement the full cache semantics?
• Coherency -- if the source is the web, then there is no guarantee that all users see the same thing at the same time, even if pulled form the same URL. This might be good for 2D Panel browser, but poor experience for render to a prim face.

HTTP Fetched Textures

Instead of full HTML on a prim, one option is client-side http fetched textures. This solves like 85% of the use-cases that HTML on a prim solves, with a lot less effort required.

Web Textures