Re: HTML Extensibility Through Script

----- 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.
http://terrainformatica.com

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