Slashdot Mirror

That's why there is the CSS3 module Fons which presents a set of properties allowing font specification by a user agent, i.e., web browsers:

http://www.w3.org/TR/css3-fonts/

The specification is implemented by the upcoming Safari 4:

http://www.apple.com/safari/features.html

Happy times for font lovers!

It's not as dead as you think. CSS3 has support for web fonts. Safari already supports it, and I think Chrome and Firefox are working on support too.

Google promoting Chrome over IE because of standards compliance makes no sense, since Google's home page is not standards compliant

I mean, it's great to have someone available to handle that sort of thing, but can you really sustain a job with this as your only skill?

I'd say yes, but mostly no. This is strictly regarding people with knowledge on only HTML and CSS, and a good eye to ensure a design is properly rendered and such graphical pieces are aligned properly.

"Yes". This is generally the case when your prospective clients are primarily technological, web-aware, and/or have been sued over their accessibility.

1. Cross-browser rendering. As more attention has been placed on cross-browser compatibility and proper rendering of designs on pages, being able to write/code syntactically-correct, clean HTML and CSS (without hacks) quickly is a very helpful skill. The real bonus: having the ability to look at a page across browsers and being able to pinpoint the issue in minutes instead of hours.
2. Accessibility. Coding truly accessible pages requires a good understanding of how to write syntactically-correct HTML in the first place, what accessible HTML tags and attributes to use and how to order these HTML elements such that when a screen reader goes through the page, the verbally-communicated output makes sense to the user. The CSS comes into play to ensure your accessibility-oriented HTML (which sometimes doesn't quite flow with how you planned to lay out these same HTML elements) still shows up nicely on the page. See the Web Accessibility Initiative Guidelines.

"Mostly No". This can be primarily the case in general.

1. Currently, HTML and CSS can generally be written properly or horribly and still render. As long as browsers are very forgiving of mistakes, some clients might not be able to note rendering differences until their favorite browser stops being forgiving and people tell them something more substantive than "your website sucks." In some cases, despite cost/benefit explanations in favor of properly-written HTML and CSS from the get-go, the client's answer might be that they were going to pay someone to maintain it anyway.
2. HTML and CSS help position shiny whistles, not make them. What, you can't actually design our site and make it awesome pretty (we expected you to create the design, and do a user analysis and such)? Ok, thanks for your time.
3. HTML and CSS are not programming languages, and therefore can't render that super awesome [insert sleek interactive widget]. If you can't understand the server-side code so you can fix the rendering issue, and the client isn't willing to let you learn as you go, you will be passed over.

The parent is not Informative, rev in this case is correct since the resource linked is a NOT the canonical page but a short-url version of the canonical page you are currently on, so the relationship is:

page A with long URL <--is the canonical url of--- page B with short URL

and NOT

page A with long URL ---is another address for the canonical url--> page B with short URL

Page A is the canonical, the long URL page is the authoritative destination, page B is just a shortcut, and not the other way around, so when in page A, if your software are looking for alternate address of that canonical page with shorter urls your software should look for reverse links containing "canonical" as the value. Links for pages that have the current page as the canonical are the ones with rev, not rel.

See http://www.w3.org/TR/html401/struct/links.html#h-12.3.1 to understand.

I admit it is a little confusing, maybe they should be using rel="alternate mirror", rel="alternate short-url" or simply rel="alternate" instead, to indicate that the link points to an alternate version of the current page. But saying that the link is of a page that points reversely to the current page that is the canonical is not wrong

Well as you totally grokked it can you tell me - shouldn't the canonical link be placed in the rel attribute?

http://www.w3.org/TR/html401/struct/links.html#h-12.3.1 says that rel is for forward links and rev is for reverse links. Canonical is a forward link as it says the primary location of the information at this onward link is where the current information is derived from. A canonical page wouldn't link out to the duplicate non-canonical copy - though if it did then that would mean the non-canonical page could have a rev="canonical" attribute in a link there.

See eg Matt Cutts post from Google, http://google.com/support/webmasters/bin/answer.py?answer=139394&topic=15262 .

Strangely rel="canonical" gives far less hits on Google than rev="canonical" which strongly suggests I'm wrong. In which case I don't get it all.

But I'm confident, so I'll stick my neck out and say canonical only fits in the rel attribute of a head link element.

The fact that the W3C information states the exact same thing: Apple refuses to license it royalty-free: "Apple Inc. has excluded all claims of patent 5,764,992"

First of all, I'm not entirely sold on the source of this story, since it does come from Opera's website.

Then don't believe opera and go straight to the W3C page that is the third link the summary: http://www.w3.org/2009/03/widgets-pag-charter

The Widgets Updates Patent Advisory Group is a Patent Advisory Group (PAG) as defined by the W3C Patent Policy (PP).

The mission of this Patent Advisory Group is to study issues and propose solutions related to a patent disclosure from Apple, Inc., concerning the Widgets 1.0: Updates Working Draft.

This PAG is triggered by Section 7.1 (PAG Formation) of the Patent Policy, which states that a PAG is triggered in the event "a patent has been disclosed that may be essential, but is not available under W3C Royalty-Free licensing requirements". The specific patent is 5,764,992 (U.S.), held by Apple, Inc. Apple Inc. has excluded all claims of patent 5,764,992 (U.S.)

I know this summary is a whopping 2 sentences long but you could have made yourself look like less of a dumbass by reading it.

According to the Patent Advisory Group they've formed to deal with this hurdle, the PAG membership includes "Advisory Committee Representatives of each Member participating in the Web Applications Working Group".

Of course, the Web Applications Working Group includes: "Apple, Inc. (4 representatives)".

Isn't it kind of a conflict of interest for Apple to be sitting on the committee that has the purview to:

• study the patent in question and discuss its impact on Widgets 1.0: Updates
• seek prior art that may apply to the use of updates in Widgets
• discuss ways to design around the claims excluded by Apple Inc.
• explore ways to come to an agreement with Apple to continue work on Widgets 1.0 Updates as a Royalty-Free specification
• write a PAG report with recommendations for the W3C Director

?

According to the Patent Advisory Group they've formed to deal with this hurdle, the PAG membership includes "Advisory Committee Representatives of each Member participating in the Web Applications Working Group".

Of course, the Web Applications Working Group includes: "Apple, Inc. (4 representatives)".

Isn't it kind of a conflict of interest for Apple to be sitting on the committee that has the purview to:

• study the patent in question and discuss its impact on Widgets 1.0: Updates
• seek prior art that may apply to the use of updates in Widgets
• discuss ways to design around the claims excluded by Apple Inc.
• explore ways to come to an agreement with Apple to continue work on Widgets 1.0 Updates as a Royalty-Free specification
• write a PAG report with recommendations for the W3C Director

?

No kidding: http://validator.w3.org/check?uri=http://www.apple.com/about/w3c/

I'm sorry, but it seems ludicrous to me that Google would consider the URL (see Tim Berners-Lee's thoughts on what URLs should and should not contain) when ranking pages. Is there any proof or documentation that this assertion is true?

For the former, all of the following are valid in both HTML 4.01 Strict and XHTML 1.0:

<link rel="copyright" href="http://www.gnu.org/licenses/gpl.html" />

While it's syntactically valid, it's a violation of the appropriate semantics:

"The COPYRIGHT relationship identifies a hypertext link to a copyright notice." (source).

The GPL isn't a copyright notice, it's a license grant. A copyright notice must identify the copyright holder and should include the date of publication.

Hey, HTTP has this neat header named "Accept-Encoding." Some valid values in this header are "gzip" and "compress".

Perhaps you see where I'm going with this...?

(In case you didn't, see the documentation for Apache's mod_deflate.)

Both WebKit and Gecko have experimental CSS properties that they safely isolate under a namespace using an obvious prefix. Here are a couple of examples. x-moz-border-radius-topleft: 7px; x-webkit-border-top-left-radius: 7px;

They don't have an "x" in front: it's just "-moz-border-radius", etc. The format is "-vendorabbreviation-property-name". So Mozilla uses "-moz", Microsoft uses "-ms", WebKit uses "-webkit" (not "-apple" for some reason), etc.

All CSS implementers do this. It's recommended by the CSS standard for experimental, incomplete, or buggy implementations of official properties. It's also used when the property is not intended to be used in web pages, only internally by browser style sheets.

It's not bad practice. This is the way that CSS was intended to be developed. CSS3 is currently under development, and there are negative consequences when browser developers tie behaviors to properties that are still in flux: sites may become dependent upon something that might have changed name and/or behavior in the final spec. (That's why they label these things as "working drafts"...they're subject to change.)

I disagree with that entirely. I think that Gecko and Webkit are doing a disservice by using their own namespaces for things like that.

The draft spec for CSS3 contains a property called "border-radius". You can see it here:

http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-border-radius.

That document is over 4 years old at this point. So if Gecko and Webkit want to implement a border radius, wouldn't it make the most sense to use the already-suggested identifier for it? When Firefox introduces support for CSS3, why make people change all of their stylesheets to use the official name instead of the hack? It would make a lot more sense to tell people to use border-radius, and then watch as more browsers start to support CSS3 and the site starts to look better and better without needing to change any code at all.

If I want borders to be rounded in both Firefox and Safari, why do I need to use 2 different CSS properties, where neither of them validate? Isn't the whole point to create valid code? It's nice that Mozilla and Webkit offered support for this before others did, but now what has happened is that people are figuring out that in order to get rounded borders you need to add "x-moz-border-radius" and "x-webkit-border-radius" rules, when what they should be learning is that you only need a single "border-radius" rule, regardless of who supports it at this point. The web pages online today telling people to use those rules are still going to be around in 5 or 10 years. The really frustrating thing is that a lof of the sites who tell people to use the hacks don't even mention the official border-radius property, so what happens when I visit those sites in Opera? Nothing, because they aren't even using the right properties.

Creating your own invalid identifiers for things like CSS or HTML attributes is a bad practice, period. It doesn't make it OK because it's Slashdot's Golden Boy Du Jour that's doing it. The bottom line is that using a proprietary name for these things does not offer a single advantage over using the already decided-upon name. Graceful degradation still occurs if they would have used border-radius.

use a 410 Gone more informative than 404
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11

http://webkit.org/projects/css/index.html

So let me understand this...

WebKit isn't yet CSS 1 compliant.

WebKit isn't yet CSS 2.1 compliant, and does not currently pass the CSS 2.1 suite.

WebKit isn't yet CSS 3 compliant, but CSS 3 isn't a finished standard yet anyway. ( http://www.w3.org/Style/CSS/current-work )

IE 8 is coming out with full CSS 2.1 compliance that passes the CSS 2.1 test suite entirely.

CSS 2.1 is the newest *completed* CSS standard level.

But according to the Intarnets, Microsoft should replace their IE Trident engine with WebKit.

Which would reduce their CSS standards support...

I'm confused.

http://webkit.org/projects/css/index.html

So let me understand this...

WebKit isn't yet CSS 1 compliant.

WebKit isn't yet CSS 2.1 compliant, and does not currently pass the CSS 2.1 suite.

WebKit isn't yet CSS 3 compliant, but CSS 3 isn't a finished standard yet anyway. ( http://www.w3.org/Style/CSS/current-work )

IE 8 is coming out with full CSS 2.1 compliance that passes the CSS 2.1 test suite entirely.

CSS 2.1 is the newest *completed* CSS standard level.

But according to the Intarnets, Microsoft should replace their IE Trident engine with WebKit.

Which would reduce their CSS standards support...

I'm confused.

Not only were they not executed, but their invention was adorned and immortalizedeven later, when the 'blink' style was introduced as a CSS text decoration.

Some people may not like it very much, but others apparently demand that their browsers have this feature...

Mozilla.com is probably a lot more web standards compliant than Microsoft.com

I don't think you need to use "probably" in that statement - you're absolutely right:
microsoft.com: Errors found while checking this document as XHTML 1.0 Transitional! 176 Errors, 36 warning(s)
mozilla.com: This document was successfully checked as XHTML 1.0 Strict!

Some small part of me was hoping for the opposite effect, just for the amusement value... but I guess sometimes things in this world really are as they should be :)

Mozilla.com is probably a lot more web standards compliant than Microsoft.com

I don't think you need to use "probably" in that statement - you're absolutely right:
microsoft.com: Errors found while checking this document as XHTML 1.0 Transitional! 176 Errors, 36 warning(s)
mozilla.com: This document was successfully checked as XHTML 1.0 Strict!

Some small part of me was hoping for the opposite effect, just for the amusement value... but I guess sometimes things in this world really are as they should be :)

IE8 doesn't even have full CSS3 support. No corner-radius? What the heck is MS thinking?

And you Sir, are clueless as to the current state of CSS3.

Huge parts of the standard are still in the working draft stage.
http://www.w3.org/Style/CSS/current-work

Supporting a subset of CSS2 or CSS3 correctly is much more important. Bugs are far worse problems than omissions.

"Can somebody tell me why programmers of open source browsers decide not to code to standards?"

The real question should be why do programmers write web apps that display differently on differing browsers. Assuming this isn't willful sabotage unlike the case of MS making Hotmail not work on Opera. This was achieved by moving text 30 pixels to the left so as to make the text look all jagged.

http://acid3.acidtests.org/
http://www.w3.org/

I'm sure absolutely nobody mentioned iCab here until now. The ones that invented ad-filtering 10 years ago (I said years). And, as I am to it, what about Amaya? THE W3C editor/browser, open-source, multiplatform, wysiwyg in the editor part? http://www.icab.de/ http://www.w3.org/Amaya/

That site looks horrible. Ironically, according to the W3C's "Markup Validation Service" it has 21 errors with it's HTML. Less than Google's homepage.

...Which has less than slashdot

That site looks horrible. Ironically, according to the W3C's "Markup Validation Service" it has 21 errors with it's HTML. Less than Google's homepage.

...Which has less than slashdot

That site looks horrible. Ironically, according to the W3C's "Markup Validation Service" it has 21 errors with it's HTML. Less than Google's homepage.

...Which has less than slashdot

That site looks horrible. Ironically, according to the W3C's "Markup Validation Service" it has 21 errors with it's HTML. Less than Google's homepage.

That site looks horrible. Ironically, according to the W3C's "Markup Validation Service" it has 21 errors with it's HTML. Less than Google's homepage.

"Uh", I just tried 3.1 beta 2 running on linux with the webfonts test page: http://www.w3.org/International/tests/test-webfonts-1 Firefox does not render the text as in the reference graphic. Opera does.

Because Acid3 only tests a small part of CSS compliance. Giving fanboys pretty number to shout about should not be a priority. Also, please don't reply to posts that you are actually not replying to. Replying to the first post is obvious attention seeking.

Acid3 doesn't "only" test a small part of CSS compliance. It tests things that a purely standards compliant browser would not implement. For one, CSS3 is largely still in development. Acid3 also tests non-standard features like Data URIs.

The real title of "first graphical browser" goes to whichever application first displayed inline graphics on a page.

That would be the browser that invented the <img> tag.

Mosaic.

The first web browser of all was WorldWideWeb.app, and it was a NeXTSTEP program. It was graphical from the beginning.

-jcr

The first web browser of all was WorldWideWeb.app, and it was a NeXTSTEP program. It was graphical from the beginning.

-jcr

Some work, some don't. It's less frustration not to bother.

(I tried pasting the list in from here, just to see which do and which don't, but apparently it contains too many junk characters...)

If some individuals or companies want to eliminate support for IE and thus greatly reduce the number of people who can see their content, that's their own choice.

Yeah, except my point was about those businesses who aspire to provide services over the web, but are prevented by doing so because they can't rely on visitors having a web browser that works. And most of the reason why they can't is because a single company has been pushing their browser on everyone while dragging their feet in adopting standards.

eb services are machine-to-machine interactions over a network. See http://www.w3.org/TR/ws-gloss/ [w3.org] and check out the definition of "web service".

Ok, to clarify, I'm not talking about some particular technical definition. I'm talking about services delivered over the web, i.e. through a web browser. The sorts of services that can be offered by a company like Google or Yahoo are most certainly dependent on browser technologies. Microsoft has been purposefully and specifically hampering the advancement of those technologies because it considers Google and Yahoo to be competitors. They've been using their dominant position in the OS market to hamper that advancement. How is this not a valid anti-trust issue?

"Only if you think having a majority market share is the only important issue, and not servicing anyone else, not making development easy, not making things work properly, not pushing technology forward, and not providing a superior product."

I'm looking at it from the perspective of a business and its customers. If some individuals or companies want to eliminate support for IE and thus greatly reduce the number of people who can see their content, that's their own choice.

"Are you really saying that the capabilities (or lack thereof) of web browsers has no effect on web services? Can you explain?"

Yes and Yes. Web services are machine-to-machine interactions over a network. See http://www.w3.org/TR/ws-gloss/ and check out the definition of "web service".

Maybe technically the way to do this is through a portal, a CC site or a search engine which only returns free-for-all content. But the non-free content needs to be kept out of the results so it doesn't get in the way.

This is precisely why CC has put such effort into making licenses and licensed works machine readable, ie, with metadata that enables such search that only gives you results with the freedoms you request.

Implementations are far from perfect, but you can go to the advanced search pages at Google, Yahoo, Flickr, and elsewhere -- some available via http://search.creativecommons.org/ -- and say that you want results that can be used commercially and for derivatives. That's a start toward what you want, and one has to start somewhere.

lists work fine on /.

I was referring specifically to definition lists (DL/DT/DD), not OL or UL.

P tags are not required to be closed. If you don't agree with that, don't hate the page author, hate the spec :)

http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.3.1

http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fslashdot.org%2Farticle.pl%3Fsid%3D09%2F02%2F19%2F2056228

Errors found while checking this document as HTML 4.01 Strict!
Result: 88 Errors, 1 warning(s)
Address: http://slashdot.org/article.pl?sid=09/02/19/2056228

http://validator.w3.org/check?uri=http://slashdot.org/&doctype=HTML+4.01+Transitional

Hmm, well it seems to handle relative table widths a little differently but nothing as radical as you're suggesting.

I suspect this is a quirks mode thing, does it pass the w3c validator? What's your DOCTYPE (you *did* set one, right?)

But the thing is, HTML was/is *designed* so that companies can extend it! (That's why HTML ignores tags it doesn't understand, for example.)

The extensibility you are referring to is for XHTML (the 'X' actually stands for eXtensible). That's an important distinction, because when a company extends XHTML, they do it using XML, which must be valid and well-formed.

I am nearly certain that microsoft.com is not being marked incompatible because of valid, well-formed XHTML extensions. I know for certain that google.com. is not.

With reference to ActiveX - the issue has always been security, not validity. Valid or not, ActiveX is a security hole you can drive a sandworm through.

HTH, HAND

Why focus only on google ?
Lets see how slashdot fares on this check !!
145 errors that make it much worse than google.

Sure Microsoft.com makes the list. The developers of the site are lazy. All they care about is that it 'works' with IE and Firefox and a few other browsers. They do NOT care one bit about W3C compliance. Do you think they put the site through the validator? I DOUBT it. Otherwise, they'd fix the 176 errors .

And then there are web developers for big companies that do the same thing. Amazon.com: 1580 errors, eBay: 226 errors and a big one for a lot of us on Slashdot I am sure (US based people), Newegg.com: 566 errors. What is so hard about validating to the standards in place? If you do it from the start, you have no problems. But developers of these sites clearly do NOT care as long as the site 'loads'.

Do not forget so many of these sites rely upon Microsoft's ASP.NET, ASP and/or IIS.

Sure Microsoft.com makes the list. The developers of the site are lazy. All they care about is that it 'works' with IE and Firefox and a few other browsers. They do NOT care one bit about W3C compliance. Do you think they put the site through the validator? I DOUBT it. Otherwise, they'd fix the 176 errors .

And then there are web developers for big companies that do the same thing. Amazon.com: 1580 errors, eBay: 226 errors and a big one for a lot of us on Slashdot I am sure (US based people), Newegg.com: 566 errors. What is so hard about validating to the standards in place? If you do it from the start, you have no problems. But developers of these sites clearly do NOT care as long as the site 'loads'.

Do not forget so many of these sites rely upon Microsoft's ASP.NET, ASP and/or IIS.

Sure Microsoft.com makes the list. The developers of the site are lazy. All they care about is that it 'works' with IE and Firefox and a few other browsers. They do NOT care one bit about W3C compliance. Do you think they put the site through the validator? I DOUBT it. Otherwise, they'd fix the 176 errors .

And then there are web developers for big companies that do the same thing. Amazon.com: 1580 errors, eBay: 226 errors and a big one for a lot of us on Slashdot I am sure (US based people), Newegg.com: 566 errors. What is so hard about validating to the standards in place? If you do it from the start, you have no problems. But developers of these sites clearly do NOT care as long as the site 'loads'.

Do not forget so many of these sites rely upon Microsoft's ASP.NET, ASP and/or IIS.