Re: HTML Extensibility Through Script

----- Original Message ----- 
From: "Doug Schepers" <doug.schepers@vectoreal.com>
To: <public-html@w3.org>
Sent: Tuesday, July 10, 2007 2:54 PM
Subject: Re: HTML Extensibility Through Script


>
> Hi, Andrew-
>
> This seems to have drifted off-topic rather quickly... To refocus, I 
> wasn't asking for a way to sniff browser strings, which is a brittle way 
> to determine the featureset of the UA.  I intended this thread to discuss 
> the possibility of conditional operators, either through a script API or 
> (preferably) via a declarative markup or featurestring.
>
> SMIL has the <switch> element, which is used in SVG to good effect. Maybe 
> something akin to that would be useful in HTML.  It's a lot more powerful 
> than a simple fallback mechanism, and not much more complex. If that isn't 
> backwards-compatible enough, some simpler variation on it might be.
>
> Andrew Fedoniouk wrote:
>>
>> ----- Original Message ----- From: "Maciej Stachowiak" <mjs@apple.com>
>>> 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.
>
> What are the use cases for loading JS through CSS?  That strike me, at 
> least superficially, as a bad design.
>

Cosider following style sheet:

@media screen/webcore
{
   @include "something-for-webcore.js" as Things;

   #mytext /* some fonts are hardly readable in webcore
       for Windows so they need to be tuned up */
   {
      font-family: Helvetica;
      font-size: 12pt;
      behaviour: Things.myText;
   }
}

@media screen/gecko
{
   @include "something-for-gecko.js" as Things;

   #mytext /* engines have different opinion
        on what font-size: Xpx; means */
   {
      font-family: Verdana;
      font-size: 14px;
      behaviour: Things.myText;
   }
}

@media screen/trident
{
   @include "something-for-ie.js" as Things;

   #mytext /* other engines treat Xem;
       differently */
   {
       margin-top: 0.9em;
       margin-bottom: 0.9em;
       behaviour: Things.myText;
   }
}

Files something-for-XXX.js may define "platform" dependent
code and varaibles. So blocks like
@media ****  { }
or
@if-defined **** { } if you wish
may serve a role of conditional switches that will allow to switch
*both* - visual styling and code .

I believe that CSS is a good place to do this so you will have centralized
visual (and behavioral) style definitions for different media types 
(different UAs
are different medias too, e.g. some use subpixel glyph rendering
and others do not)

In current reality these platform switches are spreaded through
CSS, script and HTML files. Very hard to maintain and extend in
future such codes.

HTML should be media agnostic as much as possible. IMO.

>
>> In any case originally requested feature is here already
>> through navigator.agent thing.
>
> "navigator.userAgent" give you the UA string (name/version), it doesn't 
> address my original requested feature at all.
>

As far as I understand you need something like
<if defined="mathml-v-1-2" />
   <script>...</script>
<else-if defined="mathml-v-2-0" />
   <script>...</script>
<else />
   <script>...</script>
(I use more generic solution than yours)

Question is who will maintain list of these feature names?
It should be a) standard and b) dynamic to make any sense.

(Personaly I would remove <script> element from HTML at all.
Only styles shall define visual and behavioral specifics.
But this is not realistic in current state of the web)

Andrew Fedoniouk.
http://terrainformatica.com

Received on Tuesday, 10 July 2007 23:16:47 UTC