Re: comments on WD-css3-box-20010726

* Bert Bos wrote:
>>   * pseudo-elements should take the new CSS Level 3 syntax, i.e.
>>     ::before instead of :before
>
>Both are correct (at least for pseudo-elements that existed in CSS2).

The current W3C Selectors draft should say that user agents not only
must recognize them, but that they are also valid (if this is the
intention); however, I suggest to use the CSS Level 3 notation in CSS
Level 3 modules, since the new syntax was introduced to clarify what a
class and what an element is

>>   * it should be "new" instead of "pop-up" (as in XLink)
>
>Maybe, but I think not. "New" may also mean a new top-level window,
>like some implementations do for the "target" attribute in old HTML.
>'Pop-up' is specifically a temporary window, such as a dialog box.

Links point at resources and those resources are commonly documents. I
don't think a dialog box is a proper place to render some document. I
don't know what is specific for a "temporary" window, I consider all
windows as beeing temporary. You don't want to implement a mechanism in
CSS, that creates browser windows without menus, buttons, address bar,
status bar, etc.pp. (i.e. what some people currently call "pop-up"), do
you?

>>   * it should be "replace" instead of "normal" (as you considered, as in
>>     Xlink)
>
>Yes, but the reason it isn't currently, is that there is possible
>confusion with the term "replaced element," which means something
>specific in CSS (something akin to expand/embed, in fact).

"normal" confused me, because I didn't associate something with "normal"
link behaivour and because I knew XLink and knew "replace". I don't
expect people to mix those things up. Maybe one could add some sentence
to clarify this.

>>   * the value "confirm" should be replaced by "download". The user
>>     already confirmed his action by activating the link, more
>>     confirmations aren't usable. If they are, it's up to the user agent
>>     to get a second confirmation from the user.
>
>The goal of every activation is a download; the special thing about
>this option is that the download is confirmed first. So I believe
>'confirm' is the better term.
>
>> 
>>     Instead, we need a "download" behaivour. XLink unfortunaly doesn't
>>     include this behaivour but it's needed very often. For MIME there is
>>     the Content-Disposition header, but this is not applicable for WWW 
>>     resources, since different behaivours are desireable for different
>>     links, e.g. downloading images, XHTML documents, etc.
>
>It seems we agree on the functionality, though not on the name...

Hm, I don't think so. The current draft says for "confirm": '[...] the
user has to confirm that he indeed wants to _see_ the target' (emphasis
added). Consider e.g.

  <a href='http://www.websitedev.de/svg/vxhtml11.svg'>
    Valid XHTML 1.1 SVG badge
  </a>

Your "confirm" behaivour would be (in my envoirment)

  ---[confirm link traversal]------------
  |                                     |
  | Retrieve Valid XHTML 1.1 SVG badge? |
  |                                     |
  |  [ yes ]                    [ no ]  |
  ---------------------------------------

[1]

The question "what to do with the content" isn't answered; the other
values for this property clearly define "what to do with the content",
so the "confirm" behaivour is somewhat misplaced. After activating
'yes', my Adobe SVG Viewer would render the SVG file as a new document.

My "download" behaivour would be e.g.

  ---[Save file as]----------------------
  | ...                                 |
  | ...                                 |
  |                                     |
  | File name: [vxhtml11.svg_________]  |
  | File type: [SVG graphic        [#]  |
  ---------------------------------------

The user has already confirmed, that he wants to "see" some resources,
when he activated the link; I think some additional confirmation is
useless; the user agent is responsible to interact with the user in such
cases, e.g. it retrieves the HTTP headers for some resource and asks the
user "the document is about 1,455 Gigabytes, do you really want to
continue?" or "you don't have a sound system installed; do you really
want to download and play 'Delerium - Karma - 05 - Lamentation.mp3'?";
the user agent (under configuration of the user) knows it better when to
interact with the user, this shouldn't be considered part of the authors
job and therefore not part of CSS.

If your intention was the "download" behaivour, call it "download" with
my proposed definition :-)

[1] maybe it would be wise to add some new list item to section 14.3
    that reads

  * If the source doesn't give a title, but has element content, the
    contents of that element should be displayed

>> 14.3. Confirming link traversal:
>> 
>>   * the example is invalid, the style element misses a type attribute
>
>Depends on the version of HTML...

It won't work if it's HTML 3.2, since the user agent must not assume any
default style sheet language :-)

>>   * [how] do the rel and rev attributes in XHTML interact with this @link
>>     rules?
>
>They don't interact [...]

Why wasn't this considered? I suggest some default behaivour in some
sample style sheet for XHTML 1.0 (or whatever, if any at all), e.g.

  *[rel=~alternate] { link-behaivour: replace }

>> 14.5. The ":expanded" and ":collapsed" pseudo-classes:
>> 
>>   * Huh? More selectors outside the W3C selectors draft? I thought all
>>     selectors go in the W3C Selectors module? If so, move them there, if
>>     not, move e.g. the UI selectors to the UI draft from the Selectors
>>     module
>
>Yes, they should probably go to the Selectors module. But it is a pity
>to hold up the Selectors module, which is otherwise ready, because we
>haven't finished discussing how to deal with collapsing/expanding
>elements yet.

Same goes for other selectors. Personally I don't like that the
Selectors module is in Last Call, it should be the last module, not the
first one. Hell knows, what upcoming modules may need.

>> I have more comments, hopefully I'll get some time to write them up...
>
>Yes, I hope you do.

You already got more input :-)

Thanks for your reply.
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/

Received on Monday, 30 July 2001 17:45:08 UTC