Re: ISSUE-41/ACTION-97 decentralized-extensibility

On Oct 2, 2009, at 00:22, Shelley Powers wrote:

>> Humans who write HTML save their mental state in HTML by writing  
>> HTML  comments. Is there a reason why comments with a product- 
>> specific  internal formatting wouldn't be an appropriate way to  
>> serialize  authoring tool state?
>>
>
> Yes, but comments in HTML are generally meant to be consumed by  
> humans, they're not necessarily machine friendly. Being able to use  
> formal markup to annotate the text so that it can be returned to a  
> specific state in an editor is not an unconceivable need. And a need  
> that wouldn't necessarily be met by HTML comments.

It seems to me this needs to be assessed in the context of use cases.  
It would help to know what kind of state editor vendors would like to  
save, what mechanisms they use now and what state saving they recall  
they have foregone due to lack of syntax in HTML.

>> >     * A JavaScript library processes custom tags in a browser  
>> and  > turns them into custom controls dynamically on the page.
>>
>> HTML5 addresses this use case with the data-* attributes. You take  
>> the  element that gives the best fallback behavior when the script  
>> doesn't  run and then put the script-sensitive stuff in data-*  
>> attributes.
>>
> Now, extend this concept to custom tags that can be turned into  
> custom controls AND which can also be extracted by a web bot or  
> other external service, in order to combine with like data for  
> additional purposes.

If you want the markup to be sensitive to bots, too, it looks like an  
interop requirement to me and, thus, a case for standardization rather  
than unilateral extensibility.

>> >     * A browser wants to allow custom behaviors to be defined in  
>> one  > module and attached automatically to custom elements.
>>
>> How would the custom behaviors be implemented? In page-supplied  
>> XBL2?  In native code specific to a combination of browser, OS and  
>> CPU  architecture pre-installed prior to loading the page?
>>
>> If in XBL2, wouldn't it be sufficient to be able to bind the  
>> behavior  to class attributes or to local names that have a special  
>> character  reserved for extensibility (such as '.' or '_' but *not*  
>> ':') without  having to go through the trouble of changing the  
>> namespace URI from  what the HTML5 spec says now?
>>
>> If in native code, how would the unavailability of the native code   
>> behavior for a given browser, OS and CPU combination be less bad  
>> for  the ability of the user to read Web content than the  
>> unavailability of  an NPAPI plug-in (or NPAPI-plug-in-like ActiveX  
>> control)? That is, how  would this proposal be an improvement over  
>> the current mechanism for  proprietary extensions?
>>
>> (I think the discussion about extensibility should framed in terms  
>> of  the ability of users to read content. Not in terms of the  
>> ability of  authors to write content.)
>>
>
> I don't think it's appropriate to continue to re-frame these  
> discussions. It's just as viable to discuss extensibility in terms  
> of authoring content, as it is to discuss extensibility in terms of  
> consuming.

Discussing it only from the authoring point of view is viable only in  
a write-only world. In a world where HTML is supposed to enable  
communication, the reader side should be considered as well. I my  
assessment, considering the reader side is almost systematically  
neglected when proposals for "distributed/decentralized extensibility"  
have been put forward.

> Is your main concern, and reason for re-framing this discussion in  
> terms of consumers because of your concern about automated processes  
> to read this data?

No. My main concern is Web users (people using a browser) on platforms  
other than the couple of usual ones being able to read content.

HTML already have a point for proprietary extensibility: <embed>/ 
<object> causing an NPAPI plug-in (or an ActiveX control with similar  
capabilities) to be instantiated *where available*. The most common  
application of this extension point has been extending HTML with Flash  
without the "centralization" of the W3C. There's a non-trivial amount  
of content out there that is not readable without the Flash Player  
plug-in. When a user is using a browser/OS/CPU combination for which  
the Flash Player plug-in is not available, the user is locked out of  
reading the content expressed using the Flash extension. Sometimes  
there's content in there that is very relevant to what the user is  
trying to do. (Users who need Assistive Technology are locked out  
unless an accessibility-enabled version of Flash Player is available  
for their browser/OS/CPU combination.)

Previously, this affected e.g. users of 64-bit Linux. Now Flash is  
available for 64-bit Linux, but the issue still affects e.g. S60 users  
(like me). (The "mobile" Flash Player is useless for accessing Flash  
content as actually published on sites whose authors were testing on  
desktops.)

(HTML and SVG are different, because implementations are available  
from multiple vendors and Gecko and WebKit are open for porting  
without the participation of a particular vendor, so even if someone  
refuses to port an implementation of the Open Web Platform to a  
particular computing platform an interested party can do so on their  
own initiative. I have 5 browsers on my S60 phone. 3 self-contained  
browsers and 2 thin clients for server-side browser engines.)

Now, if "decentralized extensibility" is meant to enable processing of  
subtrees using binary plug-ins whose availability may be blocked on  
the computing platform of your choice even if you were volunteering to  
port the plug-in yourself, how are things improved from the user point  
of view compared to <embed>/<object> which we already have?

> I don't understand this fixation on taking what we know works--we  
> _know_ works, we have evidence, it exists, it is neither  
> speculative, nor theory--and replacing it with something untested  
> and untried.

See Philip's emails in this thread. The proposal is *not* what has  
been tested and tried in IE.

As for Namespaces being tested and tried, they have been tested and  
tried, and they've turned out to be bad:
http://wiki.whatwg.org/wiki/Namespace_confusion

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 2 October 2009 08:02:34 UTC