Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On Sun, Apr 11, 2010 at 05:13:44PM -0400, Bob Rosenberg wrote: Also IMO the feature should be OFF unless the user SPECIFICALLY activates it (not set to ON requiring the user to turn it off to cripple it). IOW: If you want to have the Browser play Net Nanny then require the user to give permission not do it behind the user's back until the browser is told to stop messing with the page/code and display it as supplied. And I disagree entirely. Especially for something so minor as the ability to make visited links look nothing at all like unvisited links[1], software should be secure by default and require users to deliberately choose to enable less secure modes of operation, not the other way around. [1] The changes described still allow you to visually distinguish visited vs. unvisited links, provided that they still look basically the same. I don't see losing the ability to shrink visited links to a microscopic font or replace their backgrounds with biohazard warnings to be any big loss. Certainly not a big enough loss to warrant knowingly choosing a default behavior which is known to put users' privacy at risk. -- Dave Sherohman __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
At 09:20 +0900 on 04/10/2010, Philippe Wittenbergh wrote about [css-d] Changes how (some) browsers handle the a:visited ps: In short, those browsers will limit the ways the a:visited state can be styled. Color, background-color, and to some extend, outline, border are not affected, as long as you don't use alpha-transparency (rgba()), change the border-style or border-width, etc. Other changes will be ignored and fall back to what is specified for the a:link state. Am I reading this to say that font-* (such as style and weight, etc.) will be ignored and set to the :link value even when different in the :visited version? -- Bob Rosenberg RockMUG Webmaster webmas...@rockmug.org www.RockMUG.org __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
At 07:19 +0100 on 04/10/2010, Philip TAYLOR wrote about Re: [css-d]
Changes how (some) browsers handle the a:visite:
A user-controllable feature within the browser, on the other hand,
would provide a convenient way of working around any deficienc{y|ies}
in the specification(s) whilst still allowing the user to have a
fully compliant browser if he/she so wishes.
Also IMO the feature should be OFF unless the user SPECIFICALLY
activates it (not set to ON requiring the user to turn it off to
cripple it).
IOW: If you want to have the Browser play Net Nanny then require the
user to give permission not do it behind the user's back until the
browser is told to stop messing with the page/code and display it as
supplied.
--
Bob Rosenberg
RockMUG Webmaster
webmas...@rockmug.org
www.RockMUG.org
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On Apr 12, 2010, at 6:09 AM, Bob Rosenberg wrote: Am I reading this to say that font-* (such as style and weight, etc.) will be ignored and set to the :link value even when different in the :visited version? That is correct; any change in the font-* properties will be ignored an the value set on a:link (or a) used. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
Hi Philippe, (public service announcement) Both the next release versions of Gecko (tentatively named Firefox 3.7) and WebKit (Safari 5) will implement changes to the handling of the :visited pseudo-class. Google Chrome will, I suppose, also implement this. The underlying thinking is documented in this article: http://dbaron.org/mozilla/visited-privacy with some more details here: http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css - vistited/ http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history- leak/ Thanks for the heads up -- Regards, Thierry www.tjkdesign.com | articles and tutorials www.ez-css.org | ultra light CSS framework __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
May I express a personal wish that this behaviour be under
user control ? Whilst I fully understand David Baron's
rationale for the change, I do not believe that it is the
responsibility of browsers to work around security deficiencies
that arise from the correct implementation of W3C standards.
If the CSS, (X)HTML, and/or related (e.g., HTTP) specifications,
either individually or when taken together, lead to a security
deficiency, then this should be addressed at the specification
level and not by mandatory changes to a browser which would
cause the latter to deviate from the specification(s).
A user-controllable feature within the browser, on the other hand,
would provide a convenient way of working around any deficienc{y|ies}
in the specification(s) whilst still allowing the user to have a
fully compliant browser if he/she so wishes.
Philip Taylor
Philippe Wittenbergh wrote:
(public service announcement)
Both the next release versions of Gecko (tentatively named Firefox 3.7) and
WebKit (Safari 5) will implement changes to the handling of the :visited
pseudo-class. Google Chrome will, I suppose, also implement this.
In short, those browsers will limit the ways the a:visited state can be
styled. Color, background-color, and to some extend, outline, border are not
affected, as long as you don't use alpha-transparency (rgba()), change the
border-style or border-width, etc. Other changes will be ignored and fall
back to what is specified for the a:link state.
The underlying thinking is documented in this article:
http://dbaron.org/mozilla/visited-privacy
with some more details here:
http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/
http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
Gecko bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=14
WebKit bug report:
https://bugs.webkit.org/show_bug.cgi?id=24300
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On Apr 10, 2010, at 3:19 PM, Philip TAYLOR wrote: May I express a personal wish that this behaviour be under user control ? Whilst I fully understand David Baron's rationale for the change, I do not believe that it is the responsibility of browsers to work around security deficiencies that arise from the correct implementation of W3C standards. If the CSS, (X)HTML, and/or related (e.g., HTTP) specifications, either individually or when taken together, lead to a security deficiency, then this should be addressed at the specification level and not by mandatory changes to a browser which would cause the latter to deviate from the specification(s). Wrong forum for browser feature request(s). To remain on topic for this list, CSS 2.1:5.11.2 contains this sentence: UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently. http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
Philip TAYLOR wrote: May I express a personal wish that this behaviour be under user control ? Whilst I fully understand David Baron's rationale for the change, I do not believe that it is the responsibility of browsers to work around security deficiencies that arise from the correct implementation of W3C standards. If the CSS, (X)HTML, and/or related (e.g., HTTP) specifications, either individually or when taken together, lead to a security deficiency, then this should be addressed at the specification level and not by mandatory changes to a browser which would cause the latter to deviate from the specification(s). [snip] Philip Taylor This is not possible. If browser followed the current specifications, then what I did in 2008 could happen for sinister purposes, not just reverse testing of IE8. I was able track the visits from Redmond for two weeks. This was achieved by analyzing the request for transparent 1px by 1px images. http://css-class.com/cssscript/images.css You can track visited URLs very simply using hidden background images requested by using :visited. -- Alan http://css-class.com/ Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On Saturday 2010-04-10 07:19 +0100, Philip TAYLOR wrote: May I express a personal wish that this behaviour be under user control ? Whilst I fully understand David Baron's rationale for the change, I do not believe that it is the responsibility of browsers to work around security deficiencies that arise from the correct implementation of W3C standards. If the CSS, (X)HTML, and/or related (e.g., HTTP) specifications, either individually or when taken together, lead to a security deficiency, then this should be addressed at the specification level and not by mandatory changes to a browser which would cause the latter to deviate from the specification(s). It doesn't deviate from the specification; see http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes , which says: # Note. It is possible for style sheet authors to abuse the # :link and :visited pseudo-classes to determine which sites a # user has visited without the user's consent. # # UAs may therefore treat all links as unvisited links, or # implement other measures to preserve the user's privacy while # rendering visited and unvisited links differently. This falls under other measures. I'd also note that if implementation consensus develops around this solution or something similar, it would likely be worth standardizing it. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On 2010-04-10 Philippe Wittenbergh wrote: In short, those browsers will limit the ways the a:visited state can be styled. Color, background-color, and to some extend, outline, border are not affected, as long as you don't use alpha-transparency (rgba()), change the border-style or border-width, etc. Other changes will be ignored and fall back to what is specified for the a:link state. This autumn, I got into my head to style local and external links differently. First those intrusive ad popups stole double underlining. Have the sniffers stolen all reasonable options now?! From the dbaron.com page: For properties that are not permitted ..., the style for unvisited links is used instead. It's not clear to me what this means. Which ones of the following statements will be true? 1) A rule for :visited won't be used at all if any disallowed property is used in it. 2) Disallowed properties can't at all be applied to visited links. 3) Disallowed properties can be used for :visited, but only if they share all their values with :link. 4) Disallowed properties can be applied to visited links, but only by inheriting them from rules using a plain a selector with no pseudo-selector(s). 5) Disallowed properties can be applied to visited links by inheriting them from containing elements. I'd guess (4/5) are true and the others false, based on how plain a, a:link and a:visited selectors interact at present. If (3) is false many existing rules using a:link, a:visited selectors will break, but it's probably very hard to engineer things so that it's true without affecting loading times and hence safety. If (4/5) are false as well it has really come to bad times, since then color will be the only way to make links stand out! I am of the links-and-only-links-should-be-underlined persuasion, but mostly because inverse video is already the best way to make (un)visited links stand out for those with color vision problems if you want to use font shapes for their traditional emphasis purposes, not to mention that font style changes rewrap the text. Will RV now be the only way to make (visited) links stand out clearly at all? I made a comment elaborating this on the blog.mozilla.com entry Philippe linked. /BP __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class
On Apr 11, 2010, at 3:34 AM, Benct Philip Jonsson wrote:
It's not clear to me what this means. Which ones of
the following statements will be true?
1) A rule for :visited won't be used at all if
any disallowed property is used in it.
2) Disallowed properties can't at all be applied to
visited links.
3) Disallowed properties can be used for :visited, but
only if they share all their values with :link.
4) Disallowed properties can be applied to visited links,
but only by inheriting them from rules using a plain
a selector with no pseudo-selector(s).
5) Disallowed properties can be applied to visited links
by inheriting them from containing elements.
I'd guess (4/5) are true and the others false, based on how
plain a, a:link and a:visited selectors interact at
present. If (3) is false many existing rules using
a:link, a:visited selectors will break, but it's probably
very hard to engineer things so that it's true without
affecting loading times and hence safety.
To clarify: it is not necessarily that a property is disallowed; what will
happen is is that a style change between a:link and a:visited will be ignored.
To give an example:
a:link {border: 1px solid; color: blue;}
a:visited {border: 1px dashed; color: red;}
the change in border-style (from solid to dashed) will be ignored,
border-style:solid will be used for a:visited.
I made a small test file with a couple of examples along the lines of the
above. Included in the folder are 2 screenshots, the one labeled 'webkit' is
taken with the latest nightly build of WebKit and is affected by these changes.
The one labeled 'Gecko1.9.2' is taken with the current release of Firefox 3.6.3.
http://dev.l-c-n.com/CSS2/visited/
It is a work in progress. I may add more examples, depending on inspiration or
the weather or …
If (4/5) are false as well it has really come to bad times,
since then color will be the only way to make links stand
out! I am of the links-and-only-links-should-be-underlined
persuasion, but mostly because inverse video is already the
best way to make (un)visited links stand out for those with
color vision problems if you want to use font shapes for
their traditional emphasis purposes, not to mention that
font style changes rewrap the text.
Oh, but you still have lots of possibilities...
a:link {color: yellow; background: red;}
a:visited {color: red; background: yellow;}
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Changes how (some) browsers handle the a:visited pseudo-class
(public service announcement) Both the next release versions of Gecko (tentatively named Firefox 3.7) and WebKit (Safari 5) will implement changes to the handling of the :visited pseudo-class. Google Chrome will, I suppose, also implement this. In short, those browsers will limit the ways the a:visited state can be styled. Color, background-color, and to some extend, outline, border are not affected, as long as you don't use alpha-transparency (rgba()), change the border-style or border-width, etc. Other changes will be ignored and fall back to what is specified for the a:link state. The underlying thinking is documented in this article: http://dbaron.org/mozilla/visited-privacy with some more details here: http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/ http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ Gecko bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=14 WebKit bug report: https://bugs.webkit.org/show_bug.cgi?id=24300 Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
