Don't know where you get the idea of an extra request from. What they have implemented is the srcset attribute (from the WHATWG HTML spec), which means that authors can write e.g.
and the browser will then choose based on the viewport size and resolution which URL to load (whereas browsers that don't support this attribute will just load what's in src). In this case, it would load the big image if the resolution was at least 2*96dpi.
So W3C is dividing it into HTML 5 and CSS 3 and its.1 counterparts for the more experimental things which HTML5test.com look at.
Where did you get this from? The grandparent post is correct; after 2.1, CSS is divided into modules that advance individually. For instance, there is a Backgrounds and Borders module which has a level 3 spec and a level 4 spec (most of the level 4 stuff is not yet mature enough to implement). There isn't really any monolithic "CSS 3" thing, let alone "CSS 3.1".
Whatg tries to put it all together in html 5 and css 3. That is the confusion.
WHATWG's HTML spec is simply called the "HTML Living Standard", they don't use a version number at all. And the WHATWG doesn't specify anything in "CSS 3".
Among the browsers mentioned, Chrome was really the only one "lying about"/inflating its version number. IE and Opera has been around much longer, so it shouldn't be a surprise that they have released more versions.
Starcraft, Diablo 1/2 etc are truly great games. But after I switched to Linux, I have stopped buying Windows titles.
I keep my eyes open for games with Linux clients, for instance I've picked up several games with id Software's logo on the box (Doom 3+RoE, Quake 4, RTCW, Q2). To be honest I don't think many of these would have made the cut had I still been a Windows gamer, but I wanted to make a point of supporting them because of their Linux-friendliness.
I would love to buy your products if they were available on Linux.
(Opening up the source of old games would be nice too, and could help keeping them playable even in the distant future.)
Heh, didn't even occur to me to try that. None of the other apps I have open seem to create multiple selection ranges when I click-and-drag while holding Ctrl, but Firefox does (seems buggy if I try to e.g. cut/delete the selected text, though). For selectionStart/selectionEnd it looks like it chooses the one that occurs first in the textarea.
Sure, you can't really make a rich-text editor with a <textarea>, but I think that's more because the element itself was made for plain text, rather than an issue with the DOM API.
One of the things HTML5 is supposed to to something about, I guess...
There should be no problem with leap years, this is computed when reading from the Date object. For instance:
One week from Feb 24 2007 is computed as Mar 03 2007 (no leap year).
One week from Feb 24 2008 is computed as Mar 02 2008 (leap year).
As for DST, that also takes effect only when retrieving values in a relevant format. When represented in local time on my system, Thu Oct 25 2007 00:00:00 GMT+0200 gives Wed Oct 31 2007 23:00:00 GMT+0100. As far as I'm concerned this is expected. The same Date objects would be represented in UTC format as Wed, 24 Oct 2007 22:00:00 GMT and Wed, 31 Oct 2007 22:00:00 GMT, respectively. Since the internal value of a Date object is independent of time zone I don't think it would make sense to have the function give different results depending on where it's executed.
I don't think so. One of the problems with the old layouts is that everything tends to be marked up as tables, usually lots of them deeply nested. With CSS it's possible to use tabular layouts for only relevant parts of the design (if there are any), and other, more suitable techniques for the rest.
Also, expressing layout in CSS instead of in the HTML itself means that content and style is separated. Only data that's actually tabular, semantically speaking, needs to be marked up within elements. This approach can be more device-independent, consume less bandwidth (site-wide stylesheets that rarely change can be cached separately), be easier to maintain etc.
(Seems CSS3 will include special properties for multi-column layout as well, looks even easier to use)
I haven't read the book, but given the fact that creating a simple three column layout that works on every browser and looks good too is far from trivial, one can conclude two things:
Something's wrong with CSS
A better conclusion:
Something's wrong with the CSS support in at least one browser
Specifically, if IE supported display: table-cell et.al., such a layout should indeed be quite trivial. But support for this is apparently still missing, despite the fact that the relevant spec is more than 5 years old.
What I mean is that with HTML you've got all your tags, but many people don't write them correctly. How often do you write a closing P tag? Do you close your IMG tags like you should (<IMG SRC=.../>)? Most people don't.
Actually, in HTML, closing tags are optional for P elements, and forbidden for empty elements such as IMG. The empty element shorthand (<img src="..." alt="..."/>) should only be used for XHTML.
Writing correct XHTML by hand is no harder than writing correct HTML. As for comments with markup, I wouldn't let them through unchecked regardless of the markup language. Typically only a subset of elements is allowed in comments anyway, so it seems unlikely that it should be that hard to switch to XHTML.
I'm a web developer and the main reason I don't use CSS exclusively isn't because of poor browser support or rendering bugs, but CSS itself.
CSS is really really annoying. Sometimes you just need to use tables because even with a good standards compliant browser like Safari, it's just not possible to do what you want with CSS.
Things which use to be REALLY easy with tables in quirks mode (like a 3 column layout, 100% high with a header and footer) are almost impossible to implement using CSS.
Not quite sure what you mean by 100% high here, but your example should be pretty simple to express in CSS with display:table and display:table-cell. (Of course, IE doesn't understand these, so nobody uses them... but that's not the fault of CSS itself)
The author of the current Slashdot style perhaps, at least for the font size. Specifying a smaller font size than default, although common, should be avoided in most cases (possible exceptions might be copyright-type statements and the like).
That said, Firefox' default for monospace is slightly weird, as mentioned elsewhere in the comments. (The font is perfectly readable in Opera 9 at least.)
I blame the HTML markup for the annoying scrollbars. It would be more appropriate to use <blockquote> (along with sensible CSS) than <pre> for this.
love to use tables, because they WORK for displaying on various screen sizes,
No, they don't. That's why mobile browsers have to waste resources breaking such pages up to make them somewhat usable on small screen devices.
Heck, even in 1024x768 I'm occasionally forced to maximize the browser window (or use Opera's Fit-to-width function), to avoid constantly having to scroll horizontally.
First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Depends on your definition of a "page". I'm not saying you duplicate backend content. You are making a distinction between implementations, when I'm pointing out specifically presentation. To me, the same content presented with two significantly different layouts are "different pages". You still have to do the work to support/review/debug/test the different formats.
Given your "MOST page content" statement, I was thinking about your average HTML page here, not "web app" type stuff.
What I meant was that if presentation (layout) is kept to CSS, small-screen browsers can still show the pure HTML, so designers don't need to make an extra version in order to give these users access to the content.
They may of course choose to make a media="handheld" stylesheet to improve the looks, but this would be more of a once-per-site thing, not per page.
How well does the usability of slashdot discussion threads work on my blackberry? Kinda sucks.
Sure, it's not going to be optimal when a designer hasn't spent extra effort thinking about small screens, but the actual text is still readable, I hope? You just lose the horizontal margins that depend on threading level?
How about Yahoo (oh wait, they have a special UI for mobiles).
I'm assuming you mean mobile.yahoo.com. But www.yahoo.com is readable on modern handheld browsers, too. If they didn't use so many tables for layout, maybe they wouldn't need two separate URLs...
Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
Oh, right... you mean where the more featureful and easy to use sites are headed? Dynamic content exists and is growing. Mobiles haven't kept up. They are getting better than they were... so why not support CURRENT (if you can call a technology that is YEARS old "current") technologies like AJAX?
I guess "featureful and easy to use" refers to Javascript and not Flash here, since I have yet to see a Flash-only site that is not worse in terms of usability compared to HTML.
I think it may be getting there soon in terms of AJAX, but obviously mobile browser will not be able to fully keep up, considering their limits on processing power when compared to desktop PCs.
As I see it, though, most sites don't need AJAX. I guess we agree on that point. I was mainly reacting to the part about mobile browsers support supposedly requiring lots of extra effort...
Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
No they don't.
First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like.
Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
C|NET has a very funny piece by Patrick Ross, where he pooh-pooh's Congressman Rick Boucher's (D-VA) efforts to protect Fair Use by claiming that it will stifle innovation.
"You know, if there's one thing I've learned from being in the army, it's never ignore a pooh-pooh. I knew a major. He got pooh-poohed, made the mistake of ignoring the pooh-pooh - he pooh-poohed it. Fatal error, because it turned out all along that the soldier who pooh-poohed him had been pooh-poohing a lot of other officers, who pooh-poohed their pooh-poohs. In the end, we had to disband the regiment - morale totally destroyed - by pooh-pooh!"
Take it up with the W3C. See if you can get them to change the definition of
pixel in the CSS specs.
I don't see anything in the definition that suggests the user shouldn't be able to override the designer's value.
Note that the cascading order related to !important rules specifically give the user style sheet the ability to override anything in the author style sheet. I see no reason that the equivalent operation shouldn't be directly accessible through the user interface.
So considering the quote in my previous post (also note that these guidelines are maintained by the W3C), I still maintain that MSIE's way of doing font scaling is wrong.
Slashdot Mirror
Don't know where you get the idea of an extra request from. What they have implemented is the srcset attribute (from the WHATWG HTML spec), which means that authors can write e.g.
<img alt="Slashdot" src="slashdot_logo.png" srcset="slashdot_logo_big.png 2x">
and the browser will then choose based on the viewport size and resolution which URL to load (whereas browsers that don't support this attribute will just load what's in src). In this case, it would load the big image if the resolution was at least 2*96dpi.
Where did you get this from? The grandparent post is correct; after 2.1, CSS is divided into modules that advance individually. For instance, there is a Backgrounds and Borders module which has a level 3 spec and a level 4 spec (most of the level 4 stuff is not yet mature enough to implement). There isn't really any monolithic "CSS 3" thing, let alone "CSS 3.1".
WHATWG's HTML spec is simply called the "HTML Living Standard", they don't use a version number at all. And the WHATWG doesn't specify anything in "CSS 3".
Among the browsers mentioned, Chrome was really the only one "lying about"/inflating its version number. IE and Opera has been around much longer, so it shouldn't be a surprise that they have released more versions.
I made a graph of browser version timelines.
Starcraft, Diablo 1/2 etc are truly great games. But after I switched to Linux, I have stopped buying Windows titles.
I keep my eyes open for games with Linux clients, for instance I've picked up several games with id Software's logo on the box (Doom 3+RoE, Quake 4, RTCW, Q2). To be honest I don't think many of these would have made the cut had I still been a Windows gamer, but I wanted to make a point of supporting them because of their Linux-friendliness.
I would love to buy your products if they were available on Linux.
(Opening up the source of old games would be nice too, and could help keeping them playable even in the distant future.)
Bah... id Software releases their games for Linux. Heck, they even GPL their old engines, because id is just that awesome.
Blizzard, don't you want to be awesome too?
:)
Heh, didn't even occur to me to try that. None of the other apps I have open seem to create multiple selection ranges when I click-and-drag while holding Ctrl, but Firefox does (seems buggy if I try to e.g. cut/delete the selected text, though). For selectionStart/selectionEnd it looks like it chooses the one that occurs first in the textarea.
OK, I didn't read the post closely enough...
Sure, you can't really make a rich-text editor with a <textarea>, but I think that's more because the element itself was made for plain text, rather than an issue with the DOM API.
One of the things HTML5 is supposed to to something about, I guess...
myTextarea.value.substring(myTextarea.selectionStart, myTextarea.selectionEnd);
OK, those two selection properties are in HTML 5 which is only a working draft, but it works in Firefox 3 and Opera 9.5.
myTextarea.style.setProperty('color', 'green', '');
myTextarea.style.setProperty('font-size', '40px', '');
myTextarea.style.setProperty('font-family', 'serif', '');
There should be no problem with leap years, this is computed when reading from the Date object. For instance: One week from Feb 24 2007 is computed as Mar 03 2007 (no leap year). One week from Feb 24 2008 is computed as Mar 02 2008 (leap year).
As for DST, that also takes effect only when retrieving values in a relevant format. When represented in local time on my system, Thu Oct 25 2007 00:00:00 GMT+0200 gives Wed Oct 31 2007 23:00:00 GMT+0100. As far as I'm concerned this is expected. The same Date objects would be represented in UTC format as Wed, 24 Oct 2007 22:00:00 GMT and Wed, 31 Oct 2007 22:00:00 GMT, respectively. Since the internal value of a Date object is independent of time zone I don't think it would make sense to have the function give different results depending on where it's executed.
Now, admittedly, ECMAScript apparently ignores leap seconds...
// TODO: Add 898 lines
function addOneWeek(startDate) {
var oneWeekInMilliseconds = 1000*60*60*24*7;
return new Date(startDate.getTime() + oneWeekInMilliseconds);
}
Actually, we already have confirmation of a DVD-enabled Wii version for the second half of this year (got the link from Wikipedia).
I don't think so. One of the problems with the old layouts is that everything tends to be marked up as tables, usually lots of them deeply nested. With CSS it's possible to use tabular layouts for only relevant parts of the design (if there are any), and other, more suitable techniques for the rest.
Also, expressing layout in CSS instead of in the HTML itself means that content and style is separated. Only data that's actually tabular, semantically speaking, needs to be marked up within elements. This approach can be more device-independent, consume less bandwidth (site-wide stylesheets that rarely change can be cached separately), be easier to maintain etc.
(Seems CSS3 will include special properties for multi-column layout as well, looks even easier to use)
A better conclusion:
Specifically, if IE supported display: table-cell et.al., such a layout should indeed be quite trivial. But support for this is apparently still missing, despite the fact that the relevant spec is more than 5 years old.
Luckily I can see fine, but to visually impaired users, I would think e.g. menus consisting of images without alt text is a very real problem.
Actually, in HTML, closing tags are optional for P elements, and forbidden for empty elements such as IMG. The empty element shorthand (<img src="..." alt="..." />) should only be used for XHTML.
Writing correct XHTML by hand is no harder than writing correct HTML. As for comments with markup, I wouldn't let them through unchecked regardless of the markup language. Typically only a subset of elements is allowed in comments anyway, so it seems unlikely that it should be that hard to switch to XHTML.
Not quite sure what you mean by 100% high here, but your example should be pretty simple to express in CSS with display:table and display:table-cell. (Of course, IE doesn't understand these, so nobody uses them... but that's not the fault of CSS itself)
The author of the current Slashdot style perhaps, at least for the font size. Specifying a smaller font size than default, although common, should be avoided in most cases (possible exceptions might be copyright-type statements and the like).
That said, Firefox' default for monospace is slightly weird, as mentioned elsewhere in the comments. (The font is perfectly readable in Opera 9 at least.)
I blame the HTML markup for the annoying scrollbars. It would be more appropriate to use <blockquote> (along with sensible CSS) than <pre> for this.
What, specifically, is it not doing right?
Looking at the Acid2 test in 9.0 right now, and I can't see any bugs.
Got a URL?
No, they don't. That's why mobile browsers have to waste resources breaking such pages up to make them somewhat usable on small screen devices.
Heck, even in 1024x768 I'm occasionally forced to maximize the browser window (or use Opera's Fit-to-width function), to avoid constantly having to scroll horizontally.
OK...
By definition, a prime is an integer with exactly two different positive integer factors. So 1 is not a prime.
Given your "MOST page content" statement, I was thinking about your average HTML page here, not "web app" type stuff.
What I meant was that if presentation (layout) is kept to CSS, small-screen browsers can still show the pure HTML, so designers don't need to make an extra version in order to give these users access to the content.
They may of course choose to make a media="handheld" stylesheet to improve the looks, but this would be more of a once-per-site thing, not per page.
Sure, it's not going to be optimal when a designer hasn't spent extra effort thinking about small screens, but the actual text is still readable, I hope? You just lose the horizontal margins that depend on threading level?
I'm assuming you mean mobile.yahoo.com. But www.yahoo.com is readable on modern handheld browsers, too. If they didn't use so many tables for layout, maybe they wouldn't need two separate URLs...
I guess "featureful and easy to use" refers to Javascript and not Flash here, since I have yet to see a Flash-only site that is not worse in terms of usability compared to HTML.
I think it may be getting there soon in terms of AJAX, but obviously mobile browser will not be able to fully keep up, considering their limits on processing power when compared to desktop PCs.
As I see it, though, most sites don't need AJAX. I guess we agree on that point. I was mainly reacting to the part about mobile browsers support supposedly requiring lots of extra effort...
No they don't.
First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like.
Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
"You know, if there's one thing I've learned from being in the army, it's never ignore a pooh-pooh. I knew a major. He got pooh-poohed, made the mistake of ignoring the pooh-pooh - he pooh-poohed it. Fatal error, because it turned out all along that the soldier who pooh-poohed him had been pooh-poohing a lot of other officers, who pooh-poohed their pooh-poohs. In the end, we had to disband the regiment - morale totally destroyed - by pooh-pooh!"
I don't see anything in the definition that suggests the user shouldn't be able to override the designer's value.
Note that the cascading order related to !important rules specifically give the user style sheet the ability to override anything in the author style sheet. I see no reason that the equivalent operation shouldn't be directly accessible through the user interface.
So considering the quote in my previous post (also note that these guidelines are maintained by the W3C), I still maintain that MSIE's way of doing font scaling is wrong.