On Thu, Aug 11, 2016 at 6:39 PM, Karl DeSaulniers wrote:
> Hi Andre,
> Why would you target the element for its href if you already have an id?
> Not sure I am understanding that part.
>
> For checking the href, like Tom said.
>
> a[href*='#foobar'] {
> color: red;
> }
>
> or if you know #foob
> On Aug 12, 2016, at 7:32 AM, Tom Livingston wrote:
>
> On Thu, Aug 11, 2016 at 6:39 PM, Karl DeSaulniers
> wrote:
>> Hi Andre,
>> Why would you target the element for its href if you already have an id?
>> Not sure I am understanding that part.
>>
>> For checking the href, like Tom said.
>>
> On Aug 12, 2016, at 7:40 AM, Karl DeSaulniers wrote:
>
>> On Aug 12, 2016, at 7:32 AM, Tom Livingston wrote:
>>
>> On Thu, Aug 11, 2016 at 6:39 PM, Karl DeSaulniers
>> wrote:
>>> Hi Andre,
>>> Why would you target the element for its href if you already have an id?
>>> Not sure I am unders
I might muddy the waters here, but I'll try to explain how I interpreted
the goal. Consider a use-case in which your page has a long list of
anchors (imagine a sticky sidebar which scrolls with the user). The goal
(in my contrived scenario) would be to gray out the anchor which links to
the targe
Right, sorry. Was thinking about it wrong.
--
Tom Livingston | Senior Front End Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | medialogic.com
#663399
__
css-discuss [css-d@lists.css-discuss.org]
http://ww
Yes, looks like it..
https://developer.mozilla.org/en-US/docs/Web/CSS/:target
Best,
Karl DeSaulniers
Design Drumm
http://designdrumm.com
> On Aug 12, 2016, at 7:42 AM, Chris Rockwell wrote:
>
> I might muddy the waters here, but I'll try to explain how I interpreted
> the goal. Consider a
Sorry,
my first mail had an syntax error and was not clear enough, ill try again.
here is an example of :target
http://osku.de/post/css-target-source-example1.html
there we have a single css definition:
:target { background: green; }
so when we click a link (with eg. href="#foo") in the unorder
> On Aug 12, 2016, at 9:42 PM, Chris Rockwell wrote:
>
> Consider a use-case in which your page has a long list of
> anchors (imagine a sticky sidebar which scrolls with the user). The goal
> (in my contrived scenario) would be to gray out the anchor which links to
> the targeted element.
>
>
> On Aug 12, 2016, at 10:03 PM, Andre Osku Schmidt
> wrote:
>
> here is an example what it would do ("polyfilled" with javascript but
> apparently we cant just create our own pseudo-classes, so this example uses
> .source instead of :source):
> http://osku.de/post/css-target-source-example2.htm
Would this be what you're seeking?
I think this is the closest you can come if not.
h1:target
{
background: green;
}
h1:not(:target)
{
background: red;
}
Best,
Karl DeSaulniers
Design Drumm
http://designdrumm.com
> On Aug 12, 2016, at 8:03 AM, Andre Osku Schmidt
> wrote:
>
> Sorry
This might be worth taking a look at.
http://jsfiddle.net/SchizoDuckie/fzZ9d/
Best,
Karl DeSaulniers
Design Drumm
http://designdrumm.com
> On Aug 12, 2016, at 2:56 PM, Karl DeSaulniers wrote:
>
> Would this be what you're seeking?
> I think this is the closest you can come if not.
>
> h1:
At the link below, I'm having trouble getting the hover state to look the
same across browsers. On hover, there should be a red line under the
hovered-over item as wide as the thin gray line below it, as thick as that
line is.
The thickness seems to match, but the positioning is off, browser to
b
On Fri, Aug 12, 2016 at 7:52 PM, John J wrote:
> At the link below, I'm having trouble getting the hover state to look the
> same across browsers. On hover, there should be a red line under the
> hovered-over item as wide as the thin gray line below it, as thick as that
> line is.
>
> The thickne
> On Aug 13, 2016, at 8:52 AM, John J wrote:
>
> At the link below, I'm having trouble getting the hover state to look the
> same across browsers. On hover, there should be a red line under the
> hovered-over item as wide as the thin gray line below it, as thick as that
> line is.
>
> The thic
> On Aug 13, 2016, at 9:05 AM, Tom Livingston wrote:
>
> I personally wouldn't use rem's for all of the units involved with
> that structure. rem is based on the root element's font size, making
> it - I assume - dependent on how each browser renders a font, which is
> where your slight differen
On Fri, Aug 12, 2016 at 9:16 PM, Philippe Wittenbergh wrote:
>
>> On Aug 13, 2016, at 9:05 AM, Tom Livingston wrote:
>>
>> I personally wouldn't use rem's for all of the units involved with
>> that structure. rem is based on the root element's font size, making
>> it - I assume - dependent on how
> On Aug 13, 2016, at 10:19 AM, Tom Livingston wrote:
>
> The differences in font rendering between browsers, even with the same
> font specified, wouldn't position things differently?
Sure, but that has nothing to do with rem or other font(-size) related units
(ems, ch, etc).
Philippe
--
Phi
17 matches
Mail list logo
