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
# Images
#* Images should be referenced by UUID
#* Images must be full permission unless contained in the prim?
# 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
# Books
# Magazines
# Catalog
# Help Manual
# Advertisements
=== HTML from scripting ===
HTML is rendered from the output of a script.
Issues
# Script Memory Constraints
# Images
#* Images should be referenced by UUID
#* Images must be full permission unless contained in the prim??
# Links
#* Links should raise events in the scripts
Uses
# HUDs (with images)
# Changing Text Displays
# Item Vendors
# 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
# Plugins that can't be rendered
# Referenced images can't be by UUID, must be on the webpage ??
# Can't be directly tied into scripts ?? 
# At what point does the browser return the the initial URL ??
Solutions to Issues
# A URI, secondlifeasset:// , could be used to reference assets by UUID
Uses
# Web Browsing
# Books/comics
## Text on a prim
## PDF-like manuals
## Comic strips
# Magazines
# Shopping
## Vending machines
## Shopping carts
## Interface with eBay/Paypal and buy real items in-world
# Advertisements
# HUD Elements
# Gui Screens
# Text Displays
# Images on a prim
## Web-based textures
## Share Flickr and Imagebucket photos
## Comic strips
# Better interfaces for in-world systems
## Better in-world computers
## Movie screens
# Better means of in-to-out world chatting:
## Can use IRC-CGI program
### The Chatzilla extension for Firefox could be modified to run under uBrowser
## Can follow Twitter feeds
## 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
# Do all the texture operations (repeat, offset, angle, animation) apply ??
# 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
# Wouldn't this preclude HUDs?
# A way of limiting the amount of work the viewer must do
# 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
# Only displays help page in default client.
# Will not render some pages properly (Flash?).
Solutions to Issues
# Either:
## Add an address bar, or
## Implement llLaunchBrowser command in LSL.
# Tell people to only use AJAX.
Uses
# See: World Wide Web (http://en.wikipedia.org/wiki/World_Wide_Web)
# See: HTML on a Prim
# 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
# 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
# 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
# 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
Category:Shared Media