Re: Ideas for the ACSS module of CSS3

On Fri, 13 Oct 2000, Sean Palmer wrote:

>>> No: it is a "head" element. You could anchor it using XLink and
>>> frag IDs, but that would be *very* messy.
>> What I meant was that the entire idea of a navigation bar should be
>> in the HEAD using LINK elements. Or alternatively, using
>> out-of-band XLinks, but that is a new idea, whereas LINK was
>> defined 7 years ago.
> No, you could never have a navigation bar etc. that is anything but
> proper document content. I.e. why link to a navigation bar. Kind of
> defies the point really.

I find it hard to understand how the whole point of <link> defies the
whole point of <link>.

I am referring to something like:

   <head>
     <title>The construction of Widgets</title>
     <link rel="contents" href="./">
     <link rel="next" href="production.html" title="Production of Widgets">
     <link rel="previous" href="design.html" title="Design of Widgets">
     <link rel="search" href="../search/" title="Search the Site">
   </head>

This is how navigation bars were _supposed_ to be done in HTML. Doing
it this way neatly sidesteps the entire issue.


>> However, you don't need to know that -- an element, inherently, has
>> a start and an end. So just define the entire element to be
>> 'optional' as it were.
> Yes, good point. But the very existence of "content: uri()" implies
> that CSS enables some DOM interaction:
>    h1 { content: uri(h1.gif); }

No. CSS cannot affect the DOM (by definition). The 'content' property
would merely take the place of the H1's real contents in the rendering
tree (not the document tree).


>> What we are really looking at here is a way of persisting document
>> fragment states between document instances. It could be argued that
>> that is outside the scope of CSS.
> It would be a pretty pointless arguement.

Why? There is nothing else that persists document state in CSS, let
alone fragment states between document instances. I do not,
personally, even begin to understand how you would specify it.


> Your:
> body { play: normal; }
> .navbar { play: optional; }
> idea is good enough for now, and we may need to tweak it in future.

Ok, the future is now, let's tweak it. What is subideal about it?


>> I'm not sure what the 'skip' property defines, isn't the whole
>> point that it will be skipped only if the UA thinks that the
>> equivalent part of the document has already been shown?
> The problem lies in the definition of a navbar, which I am ont
> possibley going to define here.

Well that blocks discussion then, if the problem is with something
that cannot be brought to the discussion... Could you give us a
reference to this definition you allude to?


> What I really mean by it is a "grouped set of links", whatever their
> purpose.

How about the company catchphrase that appears on every page? That is
not a link but it could very well want to be made optional on
subsequent reads.


> Allowing "skipping" as well as "not playing" involves two different
> states: not playing is ignoring altogether. skipping was probably a
> bad choice of word, but it involves waht I said earlier: "The
> reasoning behind it is that a User Agent specific link (or similar),
> like 'Do you want to hear this damn navigation bar again?' could be
> placed before the damn annoying navigation bar."

Well, surely that is something that could be applied to _any_ part of
the document, and is therefore a UA-specific feature: Just like "Page
Down" works with every visual browser, you'd expect "SKIP!" to jump
the playback point to the next element or end of that element, or some
such. Thus this is not so much a CSS request as a UA feature request.


>> This still doesn't define how we establish that two documents have
>> equivalent elements that should be considered the same and skipped
>> as appropriate.
>
> Interim use of the map element, or div for grouping. That is up to
> the developer. Frag Id's classes, XLink. There are many ways to do
> it: all beyond the scope of this discussion (?)

It's very much within the scope of this discussion. You cannot define
a property to 'skip the element if it has been played in another
document during the current session' if you don't define how the UA
should be able to tell. I don't see a clean way, myself.


>> Maybe out of band links really would be a better way...?
> Coming from an XML/XHTML/XLink background, I would say "NO" ;-)

Whyever not? Out of band links would be ideal for a site-wide
navigation bar -- instead of having to embed navigation aids into
every page, you just link to a single file from every page. Just like
you can have a single CSS file apply to an entire 57,000 page site,
you could have a single XLink file apply to an entire 57,000 page
site. A maintenance dream!


>>> Yes, that is a good proposal. Howver, what I proposed gies a bit
>>> more extension to the situation: it gives CSS a more human
>>> readable element to its design.
>> That is debatable. 'content' is a full English word, 'alt' is not.
> I suggest they re-write the dictionary.

Now _that_ is out of scope for this mailing list! ;-)


>>> Bet it still takes years to see real life W3C implementations
>>> though...
>> You mean "to see real life implementation of W3C Specifications" ?
>> Yes. Not the fault of the W3C particularly though...
> No, but that as well. I mean: chances of " p { play: optional; skip:
> true; }" being valid in CSS3: 1000:1.

Why? I don't follow. If there is a clear need for something to appear
in the specification, why would it not be introduced?

-- 
Ian Hickson                                     )\     _. - ._.)       fL
Netscape, Standards Compliance QA              /. `- '  (  `--'
+1 650 937 6593                                `- , ) -> ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

Received on Saturday, 14 October 2000 10:30:52 UTC