W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: HTML Extensibility Through Script

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 10 Jul 2007 14:00:37 -0700
Message-ID: <000b01c7c335$5ebb88a0$f502000a@internal.toppro.net>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Doug Schepers" <doug.schepers@vectoreal.com>, <public-html@w3.org>

----- Original Message ----- 
From: "Maciej Stachowiak" <mjs@apple.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Doug Schepers" <doug.schepers@vectoreal.com>; <public-html@w3.org>
Sent: Tuesday, July 10, 2007 12:37 PM
Subject: Re: HTML Extensibility Through Script

> On Jul 10, 2007, at 9:17 AM, Andrew Fedoniouk wrote:
>> ----- Original Message ----- From: "Doug Schepers" 
>> <doug.schepers@vectoreal.com
>> >
>> To: <public-html@w3.org>
>> Sent: Tuesday, July 10, 2007 7:33 AM
>> Subject: HTML Extensibility Through Script
>>> ... The conversation then turned to how one might use this lib,  given 
>>> that some browsers might support MathML natively and some  not.  There 
>>> was a suggestion (a good one, I think) that a <script>  element might be 
>>> made somehow conditional (through a parameter, an  attribute, or through 
>>> encapsulation as the fallback for an  <object>, doesn't matter to me), 
>>> such that if the browser supported  a that feature natively, the script 
>>> implementation of that feature  wouldn't run.
>> <script type="application/ecmascript">
>>  if( featureXsupported() )
>>      return;
>>  // featureXemulation goes here.
>> </script>
> That's not exactly correct JavaScript (you can only exit a function,  not 
> a top-level block), but in general I agree, any features that  scripts 
> would want to switch on should be exposed for testing to  script. That way 
> you can either conditionally load whole different  scripts, or change 
> parts of scripts based on what is available.

Thanks for pointing this out, Maciej.

It, in fact, was just a short form of the following:

if( !featureXsupported() )
   // featureXemulation goes here.

BTW: Have you seen anywhere document mandating that
script inside <script> shall be executed in global context and
not as a function code context?

>> It is IMO not realistic to have some universal attribute that will  allow 
>> to filter all possible features of UA.
>> It would be nice though if UA vendors implement some
>> flag attribute like __ua_vendor/__ua_version  for the root element.
>> Such an attribute may be added while parsing DOM tree.
>> So scripts and CSS can reliably use it as a selector .
> Scripts can already get this info from navigator.userAgent. I think  the 
> fact that it's not exposed to CSS is by design - if CSS were  allowed to 
> have UA vendor/version targeted rules I think there are  better ways to do 
> it than by attributes on the root element.

Agree. Something like @media screen/webcore { ... } or
@media screen/gecko { ... } blocks will definitely
simplify life of Web devolopers. I would add in CSS ability
to load scripts too through @include or @import at-rules and
the whole system would be near the perfect.

In any case originally requested feature is here already
through navigator.agent thing.

Andrew Fedoniouk.
Received on Tuesday, 10 July 2007 21:00:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:09 UTC