Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
Lea de Groot wrote: On 10/12/2005, at 1:53 PM, Brian Cummiskey wrote: I wonder how many visits google gets in a day... Probably in the billions - plenty of people have it as their homepage. Of course, there'd be a lot of caching happening... Lea http://www.google.com.au/intl/en/press/funfacts.html http://en.wikipedia.org/wiki/Google_platform What's interesting is how they have set up their server cluster (15,000 back in 2003), which doubled from the 18 months before. If you google on that you'll find many articles. G ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
On 10/12/05, Christian Montoya [EMAIL PROTECTED] wrote: On 12/9/05, Lea de Groot [EMAIL PROTECTED] wrote: On 10/12/2005, at 1:20 AM, matt andrews wrote: Hi Lea, I completely agree. Google have somehow developed a blind spot when it comes to meeting even the basics of current web standards. As an exercise, I just threw together a valid version of the Google Search page: blog entry: http://tbp.xomerang.com/?p=18 example page: http://xomerang.com/testpages/google/validGoogle.html Hey, cool stuff! :) I thought about doing that, but decided I didn't have time. Interestingly, comparing the two pages in http://www.websiteoptimization.com/services/analyze/ shows the original is *slightly* lighter (but I bet you could beat that by removing more carriage returns, same as the original) Hmmm... the javascript isn't there... I wonder if it would add much weight - I wonder if its reused on other pages. I don't think the comparision is valid without it. :( Lea Matt's example has more text, which explains the difference... and imagine if the CSS and JS were in an external file... how often do people reuse Google throughout the day? If all those users cached the files, we're talking about drastic reductions in Google's bandwidth. It wouldn't be hard at all to lighten the page... but we knew it was a good idea even before the example. Quite right - I had started with a heavier version of the page than the default, with Google Desktop, signed in to account, etc., which added a bit of text and Javascript. Now I've done a new version, based on the simpler page that the W3C validator gets back from www.google.com. Invalid (original) page (with just 21 chars added to get a full url for the logo image): http://xomerang.com/testpages/google/invalidGoogle.html (2,654 bytes) Updated valid page, based on the above: http://xomerang.com/testpages/google/validGoogle.html (1,953 bytes) I retained the one-line Javascript in the head, but all styles are in an external CSS file: http://xomerang.com/testpages/google/validGoogle.css (636 bytes) So even for a one-off request, with no cached CSS, the valid version is 2589 bytes - *still* lighter weight than the current invalid version. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
On 12/10/05, matt andrews [EMAIL PROTECTED] wrote: On 10/12/05, Christian Montoya [EMAIL PROTECTED] wrote: Matt's example has more text, which explains the difference... and imagine if the CSS and JS were in an external file... how often do people reuse Google throughout the day? If all those users cached the files, we're talking about drastic reductions in Google's bandwidth. It wouldn't be hard at all to lighten the page... but we knew it was a good idea even before the example. Quite right - I had started with a heavier version of the page than the default, with Google Desktop, signed in to account, etc., which added a bit of text and Javascript. Now I've done a new version, based on the simpler page that the W3C validator gets back from www.google.com. Invalid (original) page (with just 21 chars added to get a full url for the logo image): http://xomerang.com/testpages/google/invalidGoogle.html (2,654 bytes) Updated valid page, based on the above: http://xomerang.com/testpages/google/validGoogle.html (1,953 bytes) I retained the one-line Javascript in the head, but all styles are in an external CSS file: http://xomerang.com/testpages/google/validGoogle.css (636 bytes) So even for a one-off request, with no cached CSS, the valid version is 2589 bytes - *still* lighter weight than the current invalid version. Nice job, you should get hired by Google, or at least paid big for that page... it would save Google millions of dollars in bandwidth. And imagine if this was done with some of their other pages (which would take a few seconds, since their sites are so simple)... we're talking about billions here. Be careful Googlebot doesn't find that page, if they cache it they might just steal the whole thing, remove the quotation marks, launch it, and pretend it was theirs all along. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
Don't you just love W3C recommendations? Google is stuck farther into the dark ages than we all thought... I just realized Google's logo is a GIF image, and you know what that means... so I downloaded it, opened it with the GIMP, and saved it as a PNG with the highest compression. The GIF: 8.35 KB The PNG: 7.86 KB 8.35 - 7.86 = .49 KB = ~502 bytes. Which times 1 billion is: a lot. Considering PNG is a W3C recommendation, this puts the total W3C savings at: 65 for Matt's page + 502 for the PNG = 567 bytes saved in total for every one off request. There might be some money in this standards thing after all. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
... Updated valid page, based on the above: http://xomerang.com/testpages/google/validGoogle.html (1,953 bytes) Ok I took your version and got it to extreme: http://rimantas.com/bits/google/google1.html (1729 bytes). What I did: got rid of some optional tags, shortened name of CSS file to one letter ( one may save four more bytes by removing extension); got rid of redundant META element (that info belongs to server config), removed widht and height from IMG: there is now use in this case to have them. Still valid HTML strict: http://validator.w3.org/check?verbose=1uri=http%3A//rimantas.com/bits/google/google1.html I retained the one-line Javascript in the head, but all styles are in an external CSS file: http://xomerang.com/testpages/google/validGoogle.css (636 bytes) So even for a one-off request, with no cached CSS, the valid version is 2589 bytes - *still* lighter weight than the current invalid version. One gotcha here: even in cached stylesheet case there is some chat going between browser and server, and it usually amounts in the range between 0.5 and 1KB. (http://rimantas.com/bits/google/headers.txt) So, for small javascript and CSS it may be better to have them in html, in case every byte counts. There is version with embeded CSS (I did not try to optimaze styles, taken as-is): http://rimantas.com/bits/google/google.html Size is 2361 bytes, but about 600 bytes of traffic are saved by having one HTTP request less. Regards, Rimantas -- http://rimantas.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
I feel you are forgetting a number of things. - Response times: Response times are every bit as important to Google as bandwidth usage is. A user should never have to wait for the Google page, or the Google search results. Ever. CSS and JavaScript in separate files means the browser needs two roundtrips to server more than currently. If rendering relies on CSS, this means unreliable response times and inevitable slower percieved loading (Try a 14.4 modem on phone lines with high interference and 75+% packet loss - those can make any page seem like it takes an eternity to load). And JavaScript loaded as a separate file means unrealiable script triggering. We wouldn't want to throw an error report in the face of our users just because they don't have the script loaded yet, do we? - Hidden bandwidth consumption: Google pages, especially the main page, are pretty light weight. Which means the HTTP headers are a considerable part of the bandwidth consumption. You double the amount of HTTP headers to send if you add two external references - both requests and responses. - Obvious bandwidth consumption: We have unneccesarily increased bandwidth consumption from the script and link elements required to reference these new files, as well as from the doctype needed to make the HTML valid. - Localisation: Google has within all probability made their pages so that minimal changes are required even to languages and scripts considerably different from English. This has to be considered for any remake with semantical markup, including the issue of the next point. - Serialisation: Not only do we want our content to be laid out the same in CSS and JavaScript enabled browsers. We also want to retain the current layout/serialisation for the content in browsers with bad or no CSS support, with terminal window textual browsers, screen readers or braille interfaces. Google may throw ugly code at us, but it isn't inaccessible as it is. This includes things such as not laying the Web/Images/Groups... out as a horizontal list instead of a single line when you have no CSS support. - Dynamic elements: Things such as being logged in/not logged in, having Google Desktop or not, sponsored links, search listings etc. all need be take in consideration. -- David liorean Andersson uri:http://liorean.web-graphics.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
On 12/10/05, liorean [EMAIL PROTECTED] wrote: I feel you are forgetting a number of things. - Response times: - Hidden bandwidth consumption: - Obvious bandwidth consumption: See Rimantas' version... I think you are focusing too much on the specific implementation of standards, and not the simple fact that if Google used standards, they would save a lot. At least Rimantas thought ahead and solved these problems by putting the CSS in the header, but let's not all bash Matt for not doing that. Also see my post on GIF vs. PNG. - Localisation: Google has within all probability made their pages so that minimal changes are required even to languages and scripts considerably different from English. This has to be considered for any remake with semantical markup, including the issue of the next point. What? I would rather modify the standards version than the original. The original uses tables, which means you have to add TD's every time you want to add another link, which are much heavier than adding LI's. Also, the standards version allows the Google codemonkeys to cut and paste the CSS, and then just edit the markup to reflect the language/localisation. - Serialisation: Not only do we want our content to be laid out the same in CSS and JavaScript enabled browsers. We also want to retain the current layout/serialisation for the content in browsers with bad or no CSS support, with terminal window textual browsers, screen readers or braille interfaces. Google may throw ugly code at us, but it isn't inaccessible as it is. This includes things such as not laying the Web/Images/Groups... out as a horizontal list instead of a single line when you have no CSS support. Huh? The bottom line is saving money, accessibility or serialisation is not so important. I would say it serializes just fine in the standards version anyway. - Dynamic elements: Things such as being logged in/not logged in, having Google Desktop or not, sponsored links, search listings etc. all need be take in consideration. How? What does that have to do with it? -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
On 10/12/05, Christian Montoya [EMAIL PROTECTED] wrote: See Rimantas' version... I think you are focusing too much on the specific implementation of standards, and not the simple fact that if Google used standards, they would save a lot. At least Rimantas thought ahead and solved these problems by putting the CSS in the header, but let's not all bash Matt for not doing that. Actually, when I started writing that, Rimantas hadn't posted his first entry yet. Also see my post on GIF vs. PNG. Well, support for gen 5 browsers maybe could speak against PNGs. Google have to consider a wider audience than most other major sites. Otherwise, yeah, it makes sense to use PNG for the size reduction. What? I would rather modify the standards version than the original. The original uses tables, which means you have to add TD's every time you want to add another link, which are much heavier than adding LI's. Also, the standards version allows the Google codemonkeys to cut and paste the CSS, and then just edit the markup to reflect the language/localisation. Maybe, but it's a consideration that hadn't been mentioned yet when I started writing that. Actually I was more thinking about the way actual search listings, sponsored links and results overview are laid out in different languages. How do they handle vertical scripts, for instance? - Serialisation: Not only do we want our content to be laid out the same in CSS and JavaScript enabled browsers. We also want to retain the current layout/serialisation for the content in browsers with bad or no CSS support, with terminal window textual browsers, screen readers or braille interfaces. Google may throw ugly code at us, but it isn't inaccessible as it is. This includes things such as not laying the Web/Images/Groups... out as a horizontal list instead of a single line when you have no CSS support. Huh? The bottom line is saving money, accessibility or serialisation is not so important. I would say it serializes just fine in the standards version anyway. Might very well do. Does the content before the search box to take so small space as to allow an 80x25 text browser to show it without scrolling? That's about as much requirements I think one can have on this issue in particular. Keeping it to a single page also in text browsers does wonders for usability in such. - Dynamic elements: Things such as being logged in/not logged in, having Google Desktop or not, sponsored links, search listings etc. all need be take in consideration. How? What does that have to do with it? Consider the entire www.google.com site. Or at least the search part of it. You probably want to create one stylesheet file and one javascript file for the entire thing, probably sent compressed if client supports it, so it gets cached and not requested again in that browser session. Also, how many users access the main page once but searches several times in a row, or move beyond the first listing page? How many access it from the Google bar or browser search fields instead of coming through the main page? The main page is just a part of the application, not the whole thing. These considerations probably make CSS layout an even better choice for reducing bandwidth consumption. -- David liorean Andersson uri:http://liorean.web-graphics.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
On 12/10/05, liorean [EMAIL PROTECTED] wrote: - Dynamic elements: Things such as being logged in/not logged in, having Google Desktop or not, sponsored links, search listings etc. all need be take in consideration. How? What does that have to do with it? Consider the entire www.google.com site. Or at least the search part of it. You probably want to create one stylesheet file and one javascript file for the entire thing, probably sent compressed if client supports it, so it gets cached and not requested again in that browser session. Also, how many users access the main page once but searches several times in a row, or move beyond the first listing page? How many access it from the Google bar or browser search fields instead of coming through the main page? The main page is just a part of the application, not the whole thing. These considerations probably make CSS layout an even better choice for reducing bandwidth consumption. That's what I was thinking. Matt's solution is almost identical to: http://search.msn.com While Rimantas is more like: http://search.yahoo.com I'm wondering what led MSN to go with external files, and Yahoo with CSS in the header. MSN is obviously much more optomized than Yahoo (the yahoo markup is a mess), and I'm thinking MSN might have picked the right choice. Their CSS file is massive and probably covers all the internal pages, which makes it worth the extra cost of having an external file. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
... I'm wondering what led MSN to go with external files, and Yahoo with CSS in the header. MSN is obviously much more optomized than Yahoo (the yahoo markup is a mess), and I'm thinking MSN might have picked the right choice. Their CSS file is massive and probably covers all the internal pages, which makes it worth the extra cost of having an external file. That's very very good point. Indeed, by tidying up SERPs and using common CSS file Google would save much much more. Optimizing only google.com start page does not make much sense: if one uses search form then he will want results pages too. Results pages are also generated by request from search box in Firefox or Opera, from google powered search in other pages. So SERPs are to be targeted if someone is serious about saving bandwidth. And in terms of web standards MSN with valid and CSS-formated start and results pages is way ahead of Google... Regards, Rimantas -- http://rimantas.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards
liorean wrote: Consider the entire www.google.com site. Or at least the search part of it. You probably want to create one stylesheet file and one javascript file for the entire thing, probably sent compressed if client supports it, so it gets cached and not requested again in that browser session. Also, how many users access the main page once but searches several times in a row, or move beyond the first listing page? How many access it from the Google bar or browser search fields instead of coming through the main page? The main page is just a part of the application, not the whole thing. These considerations probably make CSS layout an even better choice for reducing bandwidth consumption. -- David liorean Andersson There's no doubting the arguments here, but you are dealing with large organisations. Anyone who has worked within one of these large organisations as a web developer knows not to raise these issues or else they could find themselves without a job, even if their intention is only to benefit the organisation. Zeldman pointed out Yahoo's problems in DWWS, but it had little impact. *Jakob* Nielsen was utilised as the usability design person for Google's initial design, which has changed little from it original. I don't know if he's still on their payroll. Even take a look at an organisation like Telstra and it's implementation of Standards (http://telstra.com.au/standards/index.cfm). They have at least put an effort into this, but the people on this list will see the flaws in it's implementation, and it's assumptions. This movement has been going on for half a decade at Telstra, and the version 6 templates are at least 4 years old. It's almost impossible to effect these types of changes in these organisations, unless you have a position of authority. The only way to do it (so far) is to lead by example, and when there is enough evidence of good standards design implementation, then these large organisations may be willing to adapt best of practices. Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] li background image
Hello World,
I wish to make a horizontal unordered list, in which each li has a
background image. I am having trouble getting the image to display
properly, and I was wondering if you guys could lend a hand.
Below is the html and css I used for the unordered list. I have no
idea if it is valid or anything else like that. That will only be a
concern after I get it working how I want it too.
HTML:
div id=navigation
ul id=navlist
li id=activea href=# id=currentItem one/a/li
lia href=#Item two/a/li
lia href=#Item three/a/li
lia href=#Item four/a/li
lia href=#Item five/a/li
/ul
/div
CSS:
#navigation {
position: absolute;
margin-top: 160px;
margin-left: 176px;
margin-bottom: 9px;
}
#navlist li
{
display: inline;
list-style-type: none;
line-height: 26px;
padding-right: 20px;
background: transparent url(../images/button_07.gif);
background-repeat:no-repeat;
}
An example of what I am after, is on this page:
http://www.chiefcodemonkey.com/awbn/index.html
The buttons that say, The Forum; The FAQ; The F,F,F,F. I wish to
have the white text over that background image.
A copy if the image can be found here:
http://www.chiefcodemonkey.com/awbn/images/button_07.gif
Any help would be much appreciated.
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] li background image
On 12/10/05, Nathan Wheatley [EMAIL PROTECTED] wrote:
Hello World,
I wish to make a horizontal unordered list, in which each li has a
background image. I am having trouble getting the image to display
properly, and I was wondering if you guys could lend a hand.
Below is the html and css I used for the unordered list. I have no
idea if it is valid or anything else like that. That will only be a
concern after I get it working how I want it too.
Chances are it won't work if it's not valid. We've had that a million
times before, and I estimate 25 percent of the questions asked here
are answered with: validation error, validate your code and problem
solved.
CSS:
#navigation {
position: absolute;
margin-top: 160px;
margin-left: 176px;
margin-bottom: 9px;
}
You aren't the first one to make this mistake. Position absolute and
margins don't work the way you think they do. Those margins aren't
doing anything at all right now. You probably meant to do:
#navigation {
position:absolute;
top:160px;
left:176px;
}
Which is: position:absolute pulls the element from the document flow,
and places it at 0,0 (top left corner). top places it 160px from the
top. left places it 176px from the left.
Of course, using position absolute is not the best way to do it, and
neither is pixel line-heights or some of the other things, but we'll
start with this for now. Try actually implementing the list and see if
it works.
--
--
Christian Montoya
christianmontoya.com ... rdpdesign.com ... cssliquid.com
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Need help with form
On 8 Dec 2005, at 8:17 PM, Joshua Street wrote: input name=navn value= type=text You're using the name attribute, which isn't valid the name attribute *is* valid for form controls, but not other elements in XHTML strict. kind regards Terrence Wood ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Need help with form
Ah, my bad. I'd seen it misused/causing validation errors in the past, so assumed that it was just not to be used at all. Josh On 12/11/05, Terrence Wood [EMAIL PROTECTED] wrote: On 8 Dec 2005, at 8:17 PM, Joshua Street wrote: input name=navn value= type=text You're using the name attribute, which isn't valid the name attribute *is* valid for form controls, but not other elements in XHTML strict. kind regards Terrence Wood ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- Joshua Street http://www.joahua.com/ +61 (0) 425 808 469 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] li background image
Right. I set up a page with what I am after, and implement all your suggestions as they come in. Starting with yours. http://www.chiefcodemonkey.com/awbn2/ There is the address. I made the changes you stated. It now throws the allignmenat all out of whack. Can I assume that you were expecting this? ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
