W3C home > Mailing lists > Public > www-style@w3.org > April 2012

[css3-hyperlinks] Unconsistent property segmentation

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Thu, 5 Apr 2012 14:21:20 +0200
Message-ID: <94D7A0D6D0774CA89362DCF7687C2B2F@FREMYD2>
To: "CSS 3 W3C Group" <www-style@w3.org>

I know the css3-hyperlinks proposal [1] seems quite old and hasn’t been 
implemented to-date but as I saw it shared on Twitter, I would like to 
suggest to update the CSS3 Hyperlinks specification to reflect the following 

(1) The “target-new: tab” declaration is not particulary intuitive since it’s 
possible to use it conjointly with target-name to reuse an already-existing 
object (which could be of any kind: iframe, window or tab) and since some 
values of “target-name” restrict the possibilities for target-new to ‘window’ 
only. Indeed, the specification is very weak about how values are 
interacting with each other but, for example, a “modal” target will 
necessarily create a new window, how could it be a “tab”? Also, how could 
this modal window be “behind” the current window?

(2) Additonnaly, there’s no way to replicate the current (and default) 
behavior of many browsers who opens either a new window or a new tab when 
opening a link, in function of the user preference (the property clearly 
lacks an ‘auto’ value).

(3) It doesn’t feature a true replacement for window.open since there’s no 
way to customize the newly created window’s size and chrome.

(4) I’m also afraid that ‘target’ is a too generic wording for the property 
and I would prefer the use of ‘link-target’ instead (but I’m conscient it’s 
just a personnal taste some may not share).

Here’s a sort of counter-proposal that’s just there to open up the debate:

    link-target :: comma-separated list of :: any of (

        /* values targeting frames */
        current-frame (=initial)


        /* values targeting windows */

            [any of (‘frame-name’ | none)]
            [,’other-options’] /* see window.open */

            ’other-options’ /* see window.open */

        /* other values */

When a browser can’t create any valid target from a specified link-target 
option (other than ‘none’), it goes down to the next element of the 
‘link-target’ list, whose non-first options play the role of a fallback 
chain. When no element of the list has been supported, the browser use the 
default (‘auto’) behavior instead.


    .newWindow {
        link-target: new-window;

    .modalOrNothingLink {
        link-target: modal-dialog, none;

    .modalLink {
        link-target: modal-dialog, new-window(‘modal-dialog’, 

    .confirmLink {
        link-target: modal-dialog(‘height=250,width=400’), 

    .openLogin {
        link-target: new-window('login’,’height=500,width=300’), 
current-frame; /* opeing facebook login in a new window or in current frame 
in the case of a browser that don’t support tabs/windows (some smartphones) 

    .returnToParent {
        link-target: parent-window, current-frame; /* facebook login window 
returning result to parent window by setting its url or setting its own url 
in the case of a browser that don’t support tabs/windows (some smartphones) 

Hoping you did find my feedback interesting, (knowing it’s probably not the 
most important thing you have to discuss for now)

[1] http://www.w3.org/TR/css3-hyperlinks/ 
Received on Thursday, 5 April 2012 12:21:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:57 UTC