Re: Seamless iframes + CSS3 selectors = bad idea

Maciej

I am aware that styling according to the href attribute of an anchor element
is useful.

I have used it (as I said some emails ago) to detect links that end on .pdf,
also to detect emails from rapidshare..

So instead of breaking completely the support for href, I was proposing
adding an attribute, if the link has that attribute, then it will not match
any selector (like gareth;s idea of opt out).

I proposed rel=nofollow since some devs already use it to link to sensitive
part of their site.. but we can came up with a new one.. to avoid breaking
selective styling.

Greetings!!
-- Eduardo
http://www.sirdarckcat.net/

Sent from Hangzhou, Zhejiang, China

On Wed, Dec 9, 2009 at 12:10 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 8, 2009, at 8:05 AM, sird@rckc.at wrote:
>
>  passwords ARE setted some times by some apps (CUPS used it, as well as
>> Motorola's SURFBoard).. I think we loose nothing by forbidding them (wont
>> break existing apps) and we provide security for the ones that do use it..
>>
>> Anyway, if we block all inputs for me it's fine :)
>>
>> Regarding the why links:
>> <a href="?action=deleteAccount&sesc=1i19471gdh17">Delete this account</a>
>>
>> I dont propose forbiding all links, just instruct the devs to start using
>> rel=nofollow on sensitive ones or something like that.
>>
>
> I can potentially think of some use cases for styling links based on the
> contents of the href value:
>
> 1) Distinctive style to links with specific schemes (https: or ftp: for
> example).
> 2) Distinctive style for links to a particular server (onsite vs offsite).
> 3) Distinctive style for links to a particular content type, guessed based
> on file extension (put PDF icon next to likely PDFs for instance).
>
> Limiting the restriction to <a rel=nofollow> links would probably not
> overly interfere with these use cases. But do sites do that currently for
> action links containing a secret token of some kind in the URL?
>
> Regards,
> Maciej
>
>

Received on Tuesday, 8 December 2009 16:28:03 UTC