Re: [WSG] A very strange webkit bug, or Firefox?
Just use CSS standarts http://www.w3.org/Style/CSS/ and you will see that
image img / will allways have an empty space after it, because image img
/ is always displayed as display:inline + if link a href=#/ doesn't have
property as display:block, it will always display as inline. Applying
display:block (in most of cases you need to apply height value also) will
solve whatever problem you have regarding extra white space after image img
/ or link a /
*Kristaps Ancāns*
*
*
Senior web developer (coder)
Mob.: +34 644340683
E-pasts: kristaps.anc...@gmail.com
Skype: kristaps.ancans
Web: fyfi.net http://www.fyfi.net, metalguide.orghttp://www.metalguide.org,
motorolleri.lv
On Sat, Oct 1, 2011 at 05:53, Albert Scheiner alb...@scheiner.cc wrote:
Hi tee,
I played a bit around with your examples, didn't find a good answer yet
why the browsers are rendering it that way, but I can tell that it is not a
[padding-top|bottom] issue. It is rather like a white space as the space
above is exactly like adding a [nbsp;] and it stays the same even for
[padding-left or padding-right 1px or 100px], but [white-space: no-wrap]
didn't help. Firefox displays it correctly, if you remove the
[display:block] from the image and make both inline-elements again. The
other solutions is to make the A-tag a block level element by giving it a
[display: inline-block|block]. All browsers seem to like that!
Hope that helps and that maybe someone else has an answer for this
inline-elements vs. block-level-elemets behaviour ;)
Cheerio,
Albert
Am Thu Sep 29 20:17:19 2011 schrieb tee:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding
top is caused by the padding-left:13px; – any value will trigger the
padding in the EVEN set of the floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the
extra padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have
padding (top) above image (this is the reason for my or Firefox in the
subject line), however in my origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how
upset I was when I found what caused the issue – and I think I will go jump
from the bridge if anybody going to tell me the padding in the above rule
isn't the issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px;
above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines:
http://webstandardsgroup.org/**mail/guidelines.cfmhttp://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe:
http://webstandardsgroup.org/**join/unsubscribe.cfmhttp://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberhelp@webstandardsgroup.**orgmemberh...@webstandardsgroup.org
***
***
List Guidelines:
http://webstandardsgroup.org/**mail/guidelines.cfmhttp://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe:
http://webstandardsgroup.org/**join/unsubscribe.cfmhttp://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberhelp@webstandardsgroup.**orgmemberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] A very strange webkit bug, or Firefox?
Hi Albert,
Thanks for the thought. One thing I am certain though, it's triggered by
a[href^=http] and with the padding element.
I only added a[href^=http] rule at final stage, and before that the image had
no padding top issue. What is so strange is that it only occurs to the even set
of the floated block and in webkit, thus clouded my judgement too and wasted so
much time to find the cause
With this rule intact I need to add display block for grid-items li a.
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
Tee
On Sep 30, 2011, at 8:53 PM, Albert Scheiner wrote:
Hi tee,
I played a bit around with your examples, didn't find a good answer yet why
the browsers are rendering it that way, but I can tell that it is not a
[padding-top|bottom] issue. It is rather like a white space as the space
above is exactly like adding a [nbsp;] and it stays the same even for
[padding-left or padding-right 1px or 100px], but [white-space: no-wrap]
didn't help. Firefox displays it correctly, if you remove the [display:block]
from the image and make both inline-elements again. The other solutions is to
make the A-tag a block level element by giving it a [display:
inline-block|block]. All browsers seem to like that!
Hope that helps and that maybe someone else has an answer for this
inline-elements vs. block-level-elemets behaviour ;)
Cheerio,
Albert
Am Thu Sep 29 20:17:19 2011 schrieb tee:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding
top is caused by the padding-left:13px; – any value will trigger the
padding in the EVEN set of the floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the extra
padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have
padding (top) above image (this is the reason for my or Firefox in the
subject line), however in my origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how
upset I was when I found what caused the issue – and I think I will go jump
from the bridge if anybody going to tell me the padding in the above rule
isn't the issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px; above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] A very strange webkit bug, or Firefox?
On Oct 1, 2011, at 4:02 AM, Kristaps Ancāns wrote: Just use CSS standarts http://www.w3.org/Style/CSS/ and you will see that image img / will allways have an empty space after it, because image img / is always displayed as display:inline + if link a href=#/ doesn't have property as display:block, it will always display as inline. Applying display:block (in most of cases you need to apply height value also) will solve whatever problem you have regarding extra white space after image img / or link a / Well, you are correct according to the CSS spec and adding display block to a element that wrapped the image fixes it . But the issue I had is not because I didn't have display block for img. It's because webkit browsers ignore it when a[href^=http] attribute selector is used with padding left/right, and occurs in even set of floated blocks only. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] A very strange webkit bug, or Firefox?
Hi tee,
I played a bit around with your examples, didn't find a good answer
yet why the browsers are rendering it that way, but I can tell that it
is not a [padding-top|bottom] issue. It is rather like a white space as
the space above is exactly like adding a [nbsp;] and it stays the same
even for [padding-left or padding-right 1px or 100px], but
[white-space: no-wrap] didn't help. Firefox displays it correctly, if
you remove the [display:block] from the image and make both
inline-elements again. The other solutions is to make the A-tag a block
level element by giving it a [display: inline-block|block]. All
browsers seem to like that!
Hope that helps and that maybe someone else has an answer for this
inline-elements vs. block-level-elemets behaviour ;)
Cheerio,
Albert
Am Thu Sep 29 20:17:19 2011 schrieb tee:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding top is caused
by the padding-left:13px; – any value will trigger the padding in the EVEN set of the
floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the extra
padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have padding (top) above
image (this is the reason for my or Firefox in the subject line), however in my
origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how upset
I was when I found what caused the issue – and I think I will go jump from the
bridge if anybody going to tell me the padding in the above rule isn't the
issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px; above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
[WSG] A very strange webkit bug, or Firefox?
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding top
is caused by the padding-left:13px; – any value will trigger the padding in
the EVEN set of the floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the extra
padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have
padding (top) above image (this is the reason for my or Firefox in the
subject line), however in my origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how upset
I was when I found what caused the issue – and I think I will go jump from the
bridge if anybody going to tell me the padding in the above rule isn't the
issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px; above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] A very strange webkit bug, or Firefox?
Display:block for A element should solve your porblem.
*Kristaps Ancāns*
*
*
Senior web developer (coder)
Mob.: +34 644340683
E-pasts: kristaps.anc...@gmail.com
Skype: kristaps.ancans
Web: fyfi.net http://www.fyfi.net, metalguide.orghttp://www.metalguide.org,
motorolleri.lv
On Thu, Sep 29, 2011 at 12:17, tee weblis...@gmail.com wrote:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding
top is caused by the padding-left:13px; – any value will trigger the
padding in the EVEN set of the floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the
extra padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have
padding (top) above image (this is the reason for my or Firefox in the
subject line), however in my origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how
upset I was when I found what caused the issue – and I think I will go jump
from the bridge if anybody going to tell me the padding in the above rule
isn't the issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px;
above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] A very strange webkit bug, or Firefox?
Was just about to send that! :-)
Mike Flanagan
CCO Telford Computer Doctor
http://www.telfordpc.co.uk
i...@telfordpc.co.uk mailto:i...@telfordpc.co.uk
0800 058 8914
Telford Computer Doctor accepts no liability for the content of this
email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed
in writing. Any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of Telford
Computer Doctor.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
Telford Computer Doctor accepts no liability for any damage caused by
any virus transmitted by this email.
On 29/09/2011 11:26, Kristaps Ancāns wrote:
Display:block for A element should solve your porblem.
*Kristaps Ancāns*
*
*
Senior web developer (coder)
Mob.: +34 644340683
E-pasts: kristaps.anc...@gmail.com mailto:kristaps.anc...@gmail.com
Skype: kristaps.ancans
Web: fyfi.net http://www.fyfi.net, metalguide.org
http://www.metalguide.org, motorolleri.lv http://motorolleri.lv
On Thu, Sep 29, 2011 at 12:17, tee weblis...@gmail.com
mailto:weblis...@gmail.com wrote:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend,
padding top is caused by the padding-left:13px; – any value will
trigger the padding in the EVEN set of the floated block in Webkit
browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom,
the extra padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all
images have padding (top) above image (this is the reason for my
or Firefox in the subject line), however in my origninal code I
had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted
my 3 working days to find the cause and I assure you nobody can't
imagine how upset I was when I found what caused the issue – and I
think I will go jump from the bridge if anybody going to tell me
the padding in the above rule isn't the issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to
padding-left:13px; above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
mailto:memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] A very strange webkit bug, or Firefox?
On 29/09/2011 11:26, Kristaps Ancāns wrote:
Display:block for A element should solve your porblem.
Thank you!
Can't believe it! I swear that was the first thing I did when I saw that
padding in Webkit browsers.
Checked my style again and found this:
.grid-items li a img {display:block;}
Still, anybody know why the padding in that rule results different rendering in
Webkit, and only occure in even set of block?
tee
On 29/09/2011 11:26, Kristaps Ancāns wrote:
Display:block for A element should solve your porblem.
Kristaps Ancāns
Senior web developer (coder)
Mob.: +34 644340683
E-pasts: kristaps.anc...@gmail.com
Skype: kristaps.ancans
Web: fyfi.net, metalguide.org, motorolleri.lv
On Thu, Sep 29, 2011 at 12:17, tee weblis...@gmail.com wrote:
Please go to these pages from Webkit browsers (first) and Firefox.
There shouldn't have padding top for the image for We Recommend, padding
top is caused by the padding-left:13px; – any value will trigger the
padding in the EVEN set of the floated block in Webkit browsers [1].
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-left:13px;}
http://jsbin.com/ozeqon [1]
If you change padding-left to padding-top or padding-bottom, the extra
padding goes away.
In these two examples the paddings are gone.
padding-top
http://jsbin.com/ozeqon/3/
padding-bottom
http://jsbin.com/ozeqon/5
[1] If you check the page from Firefox, you will see that all images have
padding (top) above image (this is the reason for my or Firefox in the
subject line), however in my origninal code I had padding-right:13px
(which is why I first thought it's webkit bug - all in all wasted my 3
working days to find the cause and I assure you nobody can't imagine how
upset I was when I found what caused the issue – and I think I will go jump
from the bridge if anybody going to tell me the padding in the above rule
isn't the issue but my other CSS codes).
a[href^=http]{background: url(icon-external.png) no-repeat right
3px;padding-right:13px;}
http://jsbin.com/ozeqon/4/
Let see what padding:13px does. It's identical to padding-left:13px; above.
http://jsbin.com/ozeqon/6
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
