RE: [WSG] Chrome and Safari render the same...or do they?
To my eyes, the reason is that the font itself is larger on the right hand side. Naturally this will give a larger line-height, unless you have specified otherwise. Regards, Mike Mike Brockington Web Development Specialist www.calcResult.com www.stephanieBlakey.me.uk www.edinburgh.gov.uk This message does not reflect the opinions of any entity other than the author alone. From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jens-Uwe Korff Sent: 09 January 2009 05:22 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Chrome and Safari render the same...or do they? Hi all, thanks for your suggestions. I'm attaching a side-by-side comparison of a snippet of the page since I cannot put any code live, hoping the attachment gets delivered. Safari is on the left, Chrome on the right. If you cannot see the attachment, it shows how the graphical background elements are all lined up vertically, but the type is not. There's a slowly increasing offset between text lines in each of the two boxes. I'll try the rounding approach David suggested and will report back. Sorry for the delay, I've been busy with urgent tasks. Thanks, Jens The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. *** 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] Chrome and Safari render the same...or do they?
Hi all, thanks for your suggestions. I'm attaching a side-by-side comparison of a snippet of the page since I cannot put any code live, hoping the attachment gets delivered. Safari is on the left, Chrome on the right. If you cannot see the attachment, it shows how the graphical background elements are all lined up vertically, but the type is not. There's a slowly increasing offset between text lines in each of the two boxes. I'll try the rounding approach David suggested and will report back. Sorry for the delay, I've been busy with urgent tasks. Thanks, Jens The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** <>
Re: [WSG] Chrome and Safari render the same...or do they?
On Thu, 8 Jan 2009 16:36:45 +1100, Jens-Uwe Korff wrote: > Hi experts, > > I'm running into big rendering differences between Google Chrome and Safari > 3.1/PC. > They are said to render pages the same, given that they're using the same > Webkit engine. > > The differences seem to be mainly due to the different font rendering. > Safari's fonts > are way smaller, hence my boxes are smaller and shift up, breaking the layout. > > Anyone knows why this is so? Is there a workaround, i.e. a Safari-only CSS > hack? > I don't know why there would be a difference between Safari and Chrome, but I did some testing of font sizing across as many browsers as I could a few months ago. I noticed that Safari tended to "round down" fractions of a percent. So theoretical (calculated) percents may produce the effect you notice. I found that rounding up any fraction of 1% to the next higher integer (or next .01em) to work well cross-browser. This may not be your issue, but hope it helps. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome and Safari render the same...or do they?
>> From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On >> Behalf Of Johan Douma >> Sent: 08 January 2009 11:22 >> To: wsg@webstandardsgroup.org >> Subject: Re: [WSG] Chrome and Safari render the same...or do they? >> >> Just though I'd let you know about this, I actually think this is a pretty >> serious problem, because it breaks a lot of scripts and doesn't conform with >> the other browsers even though it conforms to the javascript spec. >> >> V8 (chrome's js engine) can take the values in an array in a random order. >> >> If we have my_array = new Array("val1","val2","val3","val4", etc... ); >> And we loop thru that array with for-in the values might come out as val4, >> val1, val3 >> >> The js spec actually says that it can loop thru an array in any order, but >> it actualy should be fixed to conform with other browsers. >> (https://mail.google.com/mail/?zx=zux2r51mnf08&shva=1#label/assoc/11eb4c430f775f2c) And this, my friends, is why web developers like me always insist that specs should be more specific instead of being so flexible. -- -- Christian Montoya christianmontoya.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome and Safari render the same...or do they?
I said indeed serious problem, although that is indeed debatable. for in should indeed be used carefully, it's not quite reliable and browsera all have different behaviours, although chrome's behaviour is the most unreliable (if we can call it like that) due to the order of elements returned. Even though chrome's behaviour is in agreement with the spec it doesn't do what all the other browsers do. Now, do we want to strictly follow the spec and Google leaves it like that? Or do we want it conform to what's already been done, for what? Is it in order not to break the web, or is it really to gain market share? Following the spec to stricly might make a browser too different and might stop adoption (even tho this is only one problem); most people will consider this a bug and as per spec... What's Google going to do? I'll stop there, this is an entirely other debate... Johan Douma johando...@gmail.com 2009/1/8 > Any script that relies on an array being ordered, without actually doing > a sort() is seriously . Asdeficient you mentioned yourself, this > behaviour is entirely in agreement with the JS spec. > > Regards, > Mike > > -- > *From:* li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] *On > Behalf Of *Johan Douma > *Sent:* 08 January 2009 11:22 > *To:* wsg@webstandardsgroup.org > *Subject:* Re: [WSG] Chrome and Safari render the same...or do they? > > Just though I'd let you know about this, I actually think this is a pretty > serious problem, because it breaks a lot of scripts and doesn't conform with > the other browsers even though it conforms to the javascript spec. > > V8 (chrome's js engine) can take the values in an array in a random order. > > If we have my_array = new Array("val1","val2","val3","val4", etc... ); > And we loop thru that array with for-in the values might come out as val4, > val1, val3 > > The js spec actually says that it can loop thru an array in any order, but > it actualy should be fixed to conform with other browsers. ( > https://mail.google.com/mail/?zx=zux2r51mnf08&shva=1#label/assoc/11eb4c430f775f2c > ) > > Wait and see... Maybe leave a message behind on the bug page to make Google > fix it. > > Johan Douma > johando...@gmail.com > > > *** > 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] Chrome and Safari render the same...or do they?
Any script that relies on an array being ordered, without actually doing a sort() is seriously deficient. As you mentioned yourself, this behaviour is entirely in agreement with the JS spec. Regards, Mike From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Johan Douma Sent: 08 January 2009 11:22 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Chrome and Safari render the same...or do they? Just though I'd let you know about this, I actually think this is a pretty serious problem, because it breaks a lot of scripts and doesn't conform with the other browsers even though it conforms to the javascript spec. V8 (chrome's js engine) can take the values in an array in a random order. If we have my_array = new Array("val1","val2","val3","val4", etc... ); And we loop thru that array with for-in the values might come out as val4, val1, val3 The js spec actually says that it can loop thru an array in any order, but it actualy should be fixed to conform with other browsers. (https://mail.google.com/mail/?zx=zux2r51mnf08&shva=1#label/assoc/11eb4c 430f775f2c) Wait and see... Maybe leave a message behind on the bug page to make Google fix it. Johan Douma johando...@gmail.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome and Safari render the same...or do they?
Just though I'd let you know about this, I actually think this is a pretty serious problem, because it breaks a lot of scripts and doesn't conform with the other browsers even though it conforms to the javascript spec. V8 (chrome's js engine) can take the values in an array in a random order. If we have my_array = new Array("val1","val2","val3","val4", etc... ); And we loop thru that array with for-in the values might come out as val4, val1, val3 The js spec actually says that it can loop thru an array in any order, but it actualy should be fixed to conform with other browsers. ( https://mail.google.com/mail/?zx=zux2r51mnf08&shva=1#label/assoc/11eb4c430f775f2c ) Wait and see... Maybe leave a message behind on the bug page to make Google fix it. Johan Douma johando...@gmail.com 2009/1/8 Johan Douma > Hi everybody, > > Even though Chrome is based on Webkit, Chrome actually uses another > graphics/rendering engine (the drawing layer) called Skia (source code: > http://src.chromium.org/viewvc/chrome/trunk/src/skia/). > A bit like the javascript engines, Google didn't use webkits' javascript > engine (Sqirrelfish or whatever they had before it) but developed one > themselves; V8... > > Skia came from an acquisition made by Google in 2005 of a small startup > specialising in Mobile graphics ( > http://localtechwire.com/business/local_tech_wire/news/story/1126258/). > Skia seems to be heavily used in Android and is now part of Chrome as well. > > Thus there are differences in rounded borders where the antialiasing > doesn't work so well, fonts that are smoothed differently and shadows are > rendered incorrectly. This was the case a few monts ago, but I haven't > tested it recently; it might be better now. > I've heard about opacity and png problems (rounding alpha values to 1bit) > but I haven't noticed any problems with that. > > I'm not sure why Google decided to use Skia, maybe some proprietary bits > from Quartz or from Safari that could not be used, maybe they just wanted to > use their own technology... Maybe somebody else here knows about it ? > > Cheers, > Johan Douma > johando...@gmail.com > > > 2009/1/8 Simon Pascal Klein > > I think this comes down more to which font rasterisation engine a system is >> using. I don't think Safari on Windows for example has full access to AAT >> and Quartz and thus will render type using ClearType and GDI on Windows. Add >> Firefox into the mix which uses Cairo and you'll get different results >> again, which are easily visible (for example) when comparing how Firefox >> using Cairo and ATSUI renders fonts that don't have their own small-capitals >> and thus must downsize capitals to a small-cap scale (traditionally the >> x-height of the face) and how Safari handles the same thing. (Safari, I find >> does this better—a good font to test this with is Georgia which sadly lacks >> proper real small-capitals.) >> >> To fix layout issues with content running outside your boxes use absolute, >> fixed and relative positioning instead of floats, eg: >> >> div#container { >>position: relative; >>width: 100%; >>} >> >> div.content_primary { >>width: 60%; >>left: 0; >>} >> >> div.content_secondary { >>width: 40%; >>left: 60%; >>} >> >> This way you can also quickly switch your columns around without touching >> your markup; add absolute positioning to the column that appears first in >> the markup (likely to be content_primary) and swap the left property indent. >> >> Hope any of this helps. >> >> >> —Pascal >> >> >> On 08/01/2009, at 4:36 PM, Jens-Uwe Korff wrote: >> >> Hi experts, >>> >>> I'm running into big rendering differences between Google Chrome and >>> Safari 3.1/PC. They are said to render pages the same, given that >>> they're using the same Webkit engine. >>> >>> The differences seem to be mainly due to the different font rendering. >>> Safari's fonts are way smaller, hence my boxes are smaller and shift up, >>> breaking the layout. >>> >>> Anyone knows why this is so? Is there a workaround, i.e. a Safari-only >>> CSS hack? >>> >>> Cheers, >>> >>> Jens >>> >>> The information contained in this e-mail message and any accompanying >>> files is or may be confidential. If you are not the intended recipient, any >>> use, dissemination, reliance, forwarding, printing or copying of this e-mail >>> or any attached files is unauthorised. This e-mail is subject to copyright. >>> No part of it should be reproduced, adapted or communicated without the >>> written consent of the copyright owner. If you have received this e-mail in >>> error please advise the sender immediately by return e-mail or telephone and >>> delete all copies. Fairfax does not guarantee the accuracy or completeness >>> of any information contained in this e-mail or attached files. Internet >>> communications are not secure, therefore Fairfax does not accept legal >>> responsibility for the contents of this message or attache
Re: [WSG] Chrome and Safari render the same...or do they?
Hi everybody, Even though Chrome is based on Webkit, Chrome actually uses another graphics/rendering engine (the drawing layer) called Skia (source code: http://src.chromium.org/viewvc/chrome/trunk/src/skia/). A bit like the javascript engines, Google didn't use webkits' javascript engine (Sqirrelfish or whatever they had before it) but developed one themselves; V8... Skia came from an acquisition made by Google in 2005 of a small startup specialising in Mobile graphics ( http://localtechwire.com/business/local_tech_wire/news/story/1126258/). Skia seems to be heavily used in Android and is now part of Chrome as well. Thus there are differences in rounded borders where the antialiasing doesn't work so well, fonts that are smoothed differently and shadows are rendered incorrectly. This was the case a few monts ago, but I haven't tested it recently; it might be better now. I've heard about opacity and png problems (rounding alpha values to 1bit) but I haven't noticed any problems with that. I'm not sure why Google decided to use Skia, maybe some proprietary bits from Quartz or from Safari that could not be used, maybe they just wanted to use their own technology... Maybe somebody else here knows about it ? Cheers, Johan Douma johando...@gmail.com 2009/1/8 Simon Pascal Klein > I think this comes down more to which font rasterisation engine a system is > using. I don't think Safari on Windows for example has full access to AAT > and Quartz and thus will render type using ClearType and GDI on Windows. Add > Firefox into the mix which uses Cairo and you'll get different results > again, which are easily visible (for example) when comparing how Firefox > using Cairo and ATSUI renders fonts that don't have their own small-capitals > and thus must downsize capitals to a small-cap scale (traditionally the > x-height of the face) and how Safari handles the same thing. (Safari, I find > does this better—a good font to test this with is Georgia which sadly lacks > proper real small-capitals.) > > To fix layout issues with content running outside your boxes use absolute, > fixed and relative positioning instead of floats, eg: > > div#container { >position: relative; >width: 100%; >} > > div.content_primary { >width: 60%; >left: 0; >} > > div.content_secondary { >width: 40%; >left: 60%; >} > > This way you can also quickly switch your columns around without touching > your markup; add absolute positioning to the column that appears first in > the markup (likely to be content_primary) and swap the left property indent. > > Hope any of this helps. > > > —Pascal > > > On 08/01/2009, at 4:36 PM, Jens-Uwe Korff wrote: > > Hi experts, >> >> I'm running into big rendering differences between Google Chrome and >> Safari 3.1/PC. They are said to render pages the same, given that >> they're using the same Webkit engine. >> >> The differences seem to be mainly due to the different font rendering. >> Safari's fonts are way smaller, hence my boxes are smaller and shift up, >> breaking the layout. >> >> Anyone knows why this is so? Is there a workaround, i.e. a Safari-only >> CSS hack? >> >> Cheers, >> >> Jens >> >> The information contained in this e-mail message and any accompanying >> files is or may be confidential. If you are not the intended recipient, any >> use, dissemination, reliance, forwarding, printing or copying of this e-mail >> or any attached files is unauthorised. This e-mail is subject to copyright. >> No part of it should be reproduced, adapted or communicated without the >> written consent of the copyright owner. If you have received this e-mail in >> error please advise the sender immediately by return e-mail or telephone and >> delete all copies. Fairfax does not guarantee the accuracy or completeness >> of any information contained in this e-mail or attached files. Internet >> communications are not secure, therefore Fairfax does not accept legal >> responsibility for the contents of this message or attached files. >> >> >> *** >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: memberh...@webstandardsgroup.org >> *** >> >> > --- > Simon Pascal Klein > Concept designer > > (w) http://klepas.org > (e) kle...@klepas.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/joi
Re: [WSG] Chrome and Safari render the same...or do they?
I think this comes down more to which font rasterisation engine a system is using. I don’t think Safari on Windows for example has full access to AAT and Quartz and thus will render type using ClearType and GDI on Windows. Add Firefox into the mix which uses Cairo and you’ll get different results again, which are easily visible (for example) when comparing how Firefox using Cairo and ATSUI renders fonts that don’t have their own small-capitals and thus must downsize capitals to a small-cap scale (traditionally the x-height of the face) and how Safari handles the same thing. (Safari, I find does this better—a good font to test this with is Georgia which sadly lacks proper real small- capitals.) To fix layout issues with content running outside your boxes use absolute, fixed and relative positioning instead of floats, eg: div#container { position: relative; width: 100%; } div.content_primary { width: 60%; left: 0; } div.content_secondary { width: 40%; left: 60%; } This way you can also quickly switch your columns around without touching your markup; add absolute positioning to the column that appears first in the markup (likely to be content_primary) and swap the left property indent. Hope any of this helps. —Pascal On 08/01/2009, at 4:36 PM, Jens-Uwe Korff wrote: Hi experts, I'm running into big rendering differences between Google Chrome and Safari 3.1/PC. They are said to render pages the same, given that they're using the same Webkit engine. The differences seem to be mainly due to the different font rendering. Safari's fonts are way smaller, hence my boxes are smaller and shift up, breaking the layout. Anyone knows why this is so? Is there a workaround, i.e. a Safari-only CSS hack? Cheers, Jens The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** --- Simon Pascal Klein Concept designer (w) http://klepas.org (e) kle...@klepas.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome and Safari render the same...or do they?
Jens-Uwe Korff wrote: I'm running into big rendering differences between Google Chrome and Safari 3.1/PC. They are said to render pages the same, given that they're using the same Webkit engine. They're using the WebKit engine, not necessarily the same version. Safari is at version 3.2.1 last I looked BTW. The differences seem to be mainly due to the different font rendering. Safari's fonts are way smaller, hence my boxes are smaller and shift up, breaking the layout. All my testing concludes that Safari's fonts show up ever so slightly larger than Chrome's and other browsers' on same OS (XP & Vista), but these differences are insignificant and may only occasionally cause earlier line-breaks in Safari. Would be interesting to see your example page to see if your way of styling can cause the differences you experience, or if they're caused by you setting those browsers different locally. --- No, there are no Safari vs. Chrome CSS hacks, and I hope no-one ever find or at least not use any since it'll probably do more harm than good and hit a number of other WebKit based browsers. It'll probably also target designer-bugs that are counteracted in the next versions of WebKit based browsers, and create problems that way. One should never hack live browsers. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***