LinkSubmit enhancement: <span> (etc) when disabled?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

LinkSubmit enhancement: <span> (etc) when disabled?

Nick Westgate (Work)
Hi.

A minor issue this, but I'm emboldened by the LinkSubmit jira mails.

LinkSubmit renders as text when disabled, thus losing informal
parameters like "class" or "style".

Is there a good reason why it doesn't instead output a span
or other (user definable) tag in order to preserve "style" etc?
Recently I hacked it to do just this, and it seems reasonable
that the standard library component should do something similar.

Cheers,
Nick.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: LinkSubmit enhancement: <span> (etc) when disabled?

Richard Lewis-Shell
The "good reason" was probably one of compatibility/consistency with the
other link components.

Nick Westgate wrote:

> Hi.
>
> A minor issue this, but I'm emboldened by the LinkSubmit jira mails.
>
> LinkSubmit renders as text when disabled, thus losing informal
> parameters like "class" or "style".
>
> Is there a good reason why it doesn't instead output a span
> or other (user definable) tag in order to preserve "style" etc?
> Recently I hacked it to do just this, and it seems reasonable
> that the standard library component should do something similar.
>
> Cheers,
> Nick.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: LinkSubmit enhancement: <span> (etc) when disabled? (+other link components)

Nick Westgate (Work)
Fair enough. Then I broaden my unintentionally narrow question. ;-)

Does anyone think it would be convenient if link components took
another parameter ("disabledTag", say) that directed them to
wrap their contents with a non-link tag and preserve informals?

Cheers,
Nick.


Richard Lewis-Shell wrote:

> The "good reason" was probably one of compatibility/consistency with the
> other link components.
>
> Nick Westgate wrote:
>
>>Hi.
>>
>>A minor issue this, but I'm emboldened by the LinkSubmit jira mails.
>>
>>LinkSubmit renders as text when disabled, thus losing informal
>>parameters like "class" or "style".
>>
>>Is there a good reason why it doesn't instead output a span
>>or other (user definable) tag in order to preserve "style" etc?
>>Recently I hacked it to do just this, and it seems reasonable
>>that the standard library component should do something similar.
>>
>>Cheers,
>>Nick.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: LinkSubmit enhancement: <span> (etc) when disabled? (+other link components)

Erik Hatcher

On May 18, 2005, at 10:31 PM, Nick Westgate wrote:

> Fair enough. Then I broaden my unintentionally narrow question. ;-)
>
> Does anyone think it would be convenient if link components took
> another parameter ("disabledTag", say) that directed them to
> wrap their contents with a non-link tag and preserve informals?

I think it would be more consistent for disabled links to render a  
<span> if informal parameters exist.

But that is a rather tricky issue since informals for an active link  
would be different than informals on a <span> perhaps.

     Erik



>
> Cheers,
> Nick.
>
>
> Richard Lewis-Shell wrote:
>
>> The "good reason" was probably one of compatibility/consistency  
>> with the
>> other link components.
>>
>> Nick Westgate wrote:
>>
>>
>>> Hi.
>>>
>>> A minor issue this, but I'm emboldened by the LinkSubmit jira mails.
>>>
>>> LinkSubmit renders as text when disabled, thus losing informal
>>> parameters like "class" or "style".
>>>
>>> Is there a good reason why it doesn't instead output a span
>>> or other (user definable) tag in order to preserve "style" etc?
>>> Recently I hacked it to do just this, and it seems reasonable
>>> that the standard library component should do something similar.
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: tapestry-dev-
>>> [hidden email]
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: LinkSubmit enhancement: <span> (etc) when disabled? (+other link components)

Nick Westgate (Work)
That's an interesting point. But I don't think the framework currently
prevents the developer from using inappropriate informals, does it?

Still, as you say, that's a good reason for not automatically outputting
<span> instead of <a> in the current implementation. Options seem to be:

(1) disabledSpan (output span if true) and docs warn the developer
(2) disabledAttributes (list of informals to propagate to <span>)
(3) output <span> if disabled with informals, but filter informals

The problem with (3) is that it depends on the DTD. The attributes that
differ between <span> and <a> for XHTML 1.1 and HTML 4.01 are:
Both - accesskey charset href hreflang rel rev tabindex type
HTML only - name shape coords onfocus onblur

I realize this discussion is pretty trivial compared to the current
weighty issues around Tapestry 4.0. But as you can see on tapestry-user,
there's a lot of interest in standard component improvements. Those of
us who only recently adopted Tapestry still remember (or still feel) the
pressure of trying to prove its merit to management, when we didn't have
the skill to quickly solve component issues. It's all about better OOB
experience, and - for me - the fewer components the better. (For instance
I wish that any component could be conditional.) Less is more ...

Thanks your comments Eric.
Cheers,
Nick.


Erik Hatcher wrote:

>
> On May 18, 2005, at 10:31 PM, Nick Westgate wrote:
>
>> Fair enough. Then I broaden my unintentionally narrow question. ;-)
>>
>> Does anyone think it would be convenient if link components took
>> another parameter ("disabledTag", say) that directed them to
>> wrap their contents with a non-link tag and preserve informals?
>
>
> I think it would be more consistent for disabled links to render a  
> <span> if informal parameters exist.
>
> But that is a rather tricky issue since informals for an active link  
> would be different than informals on a <span> perhaps.
>
>     Erik
>
>
>
>>
>> Cheers,
>> Nick.
>>
>>
>> Richard Lewis-Shell wrote:
>>
>>> The "good reason" was probably one of compatibility/consistency  with
>>> the
>>> other link components.
>>>
>>> Nick Westgate wrote:
>>>
>>>
>>>> Hi.
>>>>
>>>> A minor issue this, but I'm emboldened by the LinkSubmit jira mails.
>>>>
>>>> LinkSubmit renders as text when disabled, thus losing informal
>>>> parameters like "class" or "style".
>>>>
>>>> Is there a good reason why it doesn't instead output a span
>>>> or other (user definable) tag in order to preserve "style" etc?
>>>> Recently I hacked it to do just this, and it seems reasonable
>>>> that the standard library component should do something similar.
>>>>
>>>> Cheers,
>>>> Nick.
>>>>
>>>> -------------------------------------------------------------------- -
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: tapestry-dev- [hidden email]
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]