Slashdot Mirror

Do you ever use Firefox? Have you ever had the left hand side bar overlap the comments and article?

SVG tiny = mobile phones
SVG basic = PDAs
SVG = personal computers

And if you'd checked this page :
http://www.w3.org/TR/SVGMobile/#sec-eleind, which is Google hit #1 for 'svg tiny', you would see the differences between SVG tiny and SVG basic in terms of supported elements, styles (further down), etc.
In addition, anywhere where SVG basic at least reads "n/a", that's a feature that should be in SVG full.

• 16. Scripting

  SVGT [SVG-Tiny] does not support scripting. SVGB [SVG-Basic] allows optional support of scripting, and includes all of the language features from SVG 1.1 to support scripting.

• 17. Animation

  Both SVGB and SVGT support the full set of SVG 1.1's declarative animation features:

  The language features to support animation through scripting and DOM are available in SVGB. SVGT only supports declarative animation.

  SVGB and SVGT allow implicit targeting of parent elements, and targeting elements using the 'xlink:href' attribute.

  SVGB and SVGT support linear, spline, paced and discrete animations.

For a fairly comprehensive list of editors and converters check out the W3C SVG Implementations list http://www.w3.org/Graphics/SVG/SVG-Implementations . My favourites are AMAYA http://www.w3.org/Amaya/Amaya.html, Virtual Mechanics' webdraw (for simple work) http://www.virtualmechanics.com/products/dwarf/ and Sodipodi http://www.sodipodi.com/.

For a fairly comprehensive list of editors and converters check out the W3C SVG Implementations list http://www.w3.org/Graphics/SVG/SVG-Implementations . My favourites are AMAYA http://www.w3.org/Amaya/Amaya.html, Virtual Mechanics' webdraw (for simple work) http://www.virtualmechanics.com/products/dwarf/ and Sodipodi http://www.sodipodi.com/.

No, because IE will adopt a slightly different version of SVG

Well, I'm not sure if it can count as a standard already, but at least the w3 is working on it:

http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSV G-20020809/

And BTW, the XHTML + MathML part of this has been implemented in Firefox for a long time, and I love it. No hassle with putting every formula in a separate MathML document.

Take a look at http://www.w3.org/Graphics/SVG/About.html for more information on SVG.

Slashdot's open source... "no WC3 conformity by someone who's so accepting of open source"

I think you meant "W3C", but thanks for playing.

At least they don't block the w3c validator any more.

And it can't be a coincidence that the page doesn't display properly in Internet Explorer!!

Look here. This Page Is Valid XHTML 1.0 Strict! No conspiracy theories around here. Valid HTML is difficult to get looking right in IE.

more like too ignorant/incorrect to check now. is optional in the HTML standard and in fact required in the XHTML 1.0 standard.

more like too ignorant/incorrect to check now. is optional in the HTML standard and in fact required in the XHTML 1.0 standard.

And doesn't Adobe's SVG plug-in break Mozilla Suite and Firefox?

*shrug* It works fine for me.

And from a web developer's perspective, is an <embed> element or an <object> element preferred? This document seems to contradict this one.

Since it (probably!) fails miserably, this shows how well-designed all the current HTML/CSS standards are ("designed by committee", blergh).

Know what's really funny? The Acid2 test doesn't pass the W3C's CSS validator.

Let's validate Acid2's CSS: CSS validator.

* Line: 44

Parse Error - second two]
* Line: 89 Context : .parser-container div

Invalid number : color orange is not a color value : orange
* Line: 95 Context : .parser

Property error doesn't exist : }
* Line: 98 Context : .parser

Property m rgin doesn't exist : 2em
* Line: 98

Parse error - Unrecognized : };
* Line: 100 Context : .parser

Invalid number : width only 0 can be a length. You must put an unit after your number : 200
* Line: 101 Context : .parser

Parse Error - ! error;
* Line: 101 Context : .parser

Parse error - Unrecognized : }

Shame they don't stick to it:

http://validator.w3.org/check?uri=www.slashdot.org

WTF is with the acid2 test ?

XSL-FO is probably a better fit than SVG.

XSL-FO is an important standard. A comparison with PDF risks exagerating the scope, reach and capabilities of PDF though, don't you think?

SVG has similar display capabilities to PDF, plus object level animation, object level scripting and event handling.

There already is an XML based WYSIWYG document format that does everything PDF does and more, the W3C's open standard, SVG.

Yeah, I think it would be cool if someone made an XML based display format.

Even cooler, it should be design for use on the internet with features like hyperlinks and embedded objects. That would be cool! And we wouldn't have to worry about different implementations rendering things differently, since it would be an open standard that anyone could implement! We could even use those XML documents to help us mini-applications or even entire UI structures. That would be boss!

Someone should really make some XML standards like that.

In firm slashdot tradition, I have not RTFA - however...

XML. For Page layout. Intended for printing.

So what makes this "Metro" anything other than a proprietary rehash of XSL:FO?!?

We're currently using it as a middle step between our own XML based documents and PDF, using FOP. Sure, FOP doesn't fulfil all of the spec, but the spec exists, and works well.

The MIME type for SVG is "image/svg+xml" (always). And the extension for gzip compressed SVG files is ".svgz". And gzip is the only compression type which the spec allows for.

In this case, I think that the SVG spec is incomplete. It should have mentioned that serving gzipped SVG over HTTP should use "Content-Type: image/svg+xml" and also "Content-Encoding: gzip". See section 14.11 in RFC 2616 (HTTP/1.1) for details. While the information about the MIME type is correct and is not affected by the compression used, the information about encoding should have been mentioned in the spec.

The problem with the SVG image linked here is that the server is sending the compressed SVG file without specifying the Content-Encoding. Because of that, most browsers will not be able to read the file. That's why they recommend using Opera 8 for viewing it. I suppose that Opera 8 uses file sniffing as a fallback method and is able to detect that the file has been gzipped (just like most browsers can open a JPEG file even if it was sent with the MIME type image/gif).

Why on earth would you serve a perfectly standard Inkscape SVG that you had then gzipped as image/svg+xml? Isn't that misleading?

No it's not. Read the spec , and you'll find that this is completely correct.

The MIME type for SVG is "image/svg+xml" (always). And the extension for gzip compressed SVG files is ".svgz". And gzip is the only compression type which the spec allows for.

Comments can cross multiple lines. A comment continues until the end marker is encountered. Once a comment has begun, the only thing an HTML or XHTML parser recognizes as a command is the end of comment tag, which is a double dash (--) not immediately preceeded by an exclamation point. ( xhtml comments)

I just tried the pasting "if[IE]" comment into NVU, and while it did collapse the whole thing down to one line (see below), it worked as expected in both firefox and IE 6.(Firefox displayed nothing, IE displayed a block element) The only pitfall I found is when pasting the <!-- part. If you put that in the comment text box, the generated comment is <!--<!-- with a matching set of closing tags, the second of which is (correctly) ignored. I've never had this problem since I do this sort of thing in note pad once I got a page looking the way I want it. What's more, both types (block and inline) of comment validate.

<style type="text/css">p.showIE{display:none;}</style>

<!--[if IE]><style type="text/css" />p.showIE {display:block;}</style><![endif]-->

It seems like the IE7 developer team didn't even manage to make a blog validate to HTML 4.0. How can this be possible?

RDF (Resource Description Framework) is a meta-language, like XML. Except it's not even really a language, it's a model. Extra confusing because there are different syntaxes available, one of which is XML.

RSS 2.0 (Really Simple Syndication, I think) is what most people are talking about when they say RSS these days. Based on the original RSS 0.9x format, some people complain it's underspecified.

RSS 1.0 (RDF Site Summary) is a completely different specification, using the same basic concept & elements but all in the RDF model. Its detractors claim that RDF is too damned confusing (I won't argue there) and make the usual comments about ivory-tower intellectuals.

Atom's (not an acronym) the new kid, it hasn't actually been released yet but should be coming very soon - within weeks/months. Difficult to say anything about it until it's finalised, but it's got some nice stuff. I particularly like the Atom API. Clean & RESTful, mmm-mmm good. In my opinion (Atom ~= RSS 1.0) > RSS 2.0, but don't take my word for it as I'm fairly new to all this.

Gecko polls servers for changed content when moving through history. As far as I know, Opera is the only major browser that gets that part of HTTP/1.1 right.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

They support CSS3 selectors, which are still candidate recommendations.

I think it's that their support for the border module is terribly incomplete, so they're not going to suggest that they support any of it quite yet.

Instead of implementing a vendor-specific tag, why not support the proposed CSS3 border-radius property?

The application forms are in XFDL, if that helps anyone.

In 200 years, no one will be able to make since of a jpg or png, and these are well known and well understood formats.

You won't be able to read ANY cd that is 20 years old

Really? So why does searching the W3C site for XUL only give a load of mailing list posts? Why is XUL not mentioned in their site index? Is it, perhaps, because it is a Mozilla technology? The specifications are published, so it is an open specification, but it is not endorsed by the W3C.

If you still think this is an error, please email acid2Feedback /\T webstandards.org.

If you still think this is an error, please email acid2Feedback /\T webstandards.org.

Maybe you should make your site standards compliant too :P

The text goes over the picture of the monitor and keyboard in Firefox 1.0.2 on SuSE 9.2, which I assume was not your intended rendering.

Here are some errors

• Microsoft Corporation
• Mozilla Foundation
• Opera Software

Firstly, the errors are there on purpose, to check the error handling conformance.

As for whether the <textarea> is shrink-to-fit or not, the CSS 2.1 specification has this to say.

If all three of 'left', 'width', and 'right' are 'auto' [This is the case] : First set any 'auto' values for 'margin-left' and 'margin-right' to 0. Then, if 'direction' is 'ltr' [This is the case] set 'left' to the static position and apply rule number three below; otherwise, set 'right' to the static position and apply rule number one below.

The "rule number three" says that it is shrink-to-fit.

Your mistake is in referring to 10.3.3, which explains what to do for non-replaced block-level elements in normal flow. You should be referring to 10.3.7, which explains what to do for non-replaced block-level elements that are absolutely positioned.

Webstandards.org may have good intentions, but I'm not sure I trust their test or their organization. For one thing, someone has pointed out that the W3C's CSS validator rejects it. (This link currently slashdotted.)

Gecko renders part of the second row of the face at the right edge of the viewport. I believe that that is actually the correct behavior according to the specifications. Row 2 is generated by

<blockquote><address> </address></blockquote>

The blockquote is a block-level element with unspecified width, so except for the 60px left margin, it should occupy the entire width of the containing block (CSS 2.1, Sec 10.3.3). Therefore, the address element, which is floated to the right within the blockquote, is correctly placed at the right edge of the viewport. I don't see why the "shrink-to-fit" rule for computing the width of the blockquote should apply as they claim it does. There may be other errors, but I haven't investigated further.

When the W3C publishes a test, one can be pretty sure that it's authoritative. But who is behind webstandards.org? They claim to be a grassroots coalition, yet I don't see where on their website they invite site visitors to join or contribute to their cause.

Their explanation of the test lacks a contact address at the end to report errors. It seems rather careless of them to publish the test in that state, and it doesn't inspire confidence in the rest of the test.

It's good to see someone making an effort. I do hope that this test will help browsers improve, but I wouldn't trust that the test itself is 100% accurate, either. I would love to see the W3C devise more compliance tests of this sort.

Webstandards.org may have good intentions, but I'm not sure I trust their test or their organization. For one thing, someone has pointed out that the W3C's CSS validator rejects it. (This link currently slashdotted.)

Gecko renders part of the second row of the face at the right edge of the viewport. I believe that that is actually the correct behavior according to the specifications. Row 2 is generated by

<blockquote><address> </address></blockquote>

The blockquote is a block-level element with unspecified width, so except for the 60px left margin, it should occupy the entire width of the containing block (CSS 2.1, Sec 10.3.3). Therefore, the address element, which is floated to the right within the blockquote, is correctly placed at the right edge of the viewport. I don't see why the "shrink-to-fit" rule for computing the width of the blockquote should apply as they claim it does. There may be other errors, but I haven't investigated further.

When the W3C publishes a test, one can be pretty sure that it's authoritative. But who is behind webstandards.org? They claim to be a grassroots coalition, yet I don't see where on their website they invite site visitors to join or contribute to their cause.

Their explanation of the test lacks a contact address at the end to report errors. It seems rather careless of them to publish the test in that state, and it doesn't inspire confidence in the rest of the test.

It's good to see someone making an effort. I do hope that this test will help browsers improve, but I wouldn't trust that the test itself is 100% accurate, either. I would love to see the W3C devise more compliance tests of this sort.

Webstandards.org may have good intentions, but I'm not sure I trust their test or their organization. For one thing, someone has pointed out that the W3C's CSS validator rejects it. (This link currently slashdotted.)

Gecko renders part of the second row of the face at the right edge of the viewport. I believe that that is actually the correct behavior according to the specifications. Row 2 is generated by

<blockquote><address> </address></blockquote>

The blockquote is a block-level element with unspecified width, so except for the 60px left margin, it should occupy the entire width of the containing block (CSS 2.1, Sec 10.3.3). Therefore, the address element, which is floated to the right within the blockquote, is correctly placed at the right edge of the viewport. I don't see why the "shrink-to-fit" rule for computing the width of the blockquote should apply as they claim it does. There may be other errors, but I haven't investigated further.

When the W3C publishes a test, one can be pretty sure that it's authoritative. But who is behind webstandards.org? They claim to be a grassroots coalition, yet I don't see where on their website they invite site visitors to join or contribute to their cause.

Their explanation of the test lacks a contact address at the end to report errors. It seems rather careless of them to publish the test in that state, and it doesn't inspire confidence in the rest of the test.

It's good to see someone making an effort. I do hope that this test will help browsers improve, but I wouldn't trust that the test itself is 100% accurate, either. I would love to see the W3C devise more compliance tests of this sort.

I'm confused, is this supposed to be valid CSS2? The W3C CSS validator finds 8 errors in the page.

-molo

CSS validator results

* Line: 46
Parse Error - second two]
* Line: 91 Context : .parser-container div
Invalid number : color orange is not a color value : orange
* Line: 97 Context : .parser
Property error doesn't exist : }
* Line: 100 Context : .parser
Property m rgin doesn't exist : 2em
* Line: 100
Parse error - Unrecognized : };
* Line: 102 Context : .parser
Invalid number : width only 0 can be a length. You must put an unit after your number : 200
* Line: 103 Context : .parser
Parse Error - ! error;
* Line: 103 Context : .parser
Parse error - Unrecognized : }

The W3C CSS validator fails to validate that page. So is it really a failure when the page does not validate?

I truly wished that they would at least check if the CSS is valid first...

http://jigsaw.w3.org/css-validator/validator?uri=h ttp%3A%2F%2Fwebstandards.org%2Fact%2Facid2%2Ftest. html%23top&warning=1&profile=css2&usermedium=all

Errors
URI : http://webstandards.org/act/acid2/test.html#top

* Line: 46

Parse Error - second two]
* Line: 91 Context : .parser-container div

Invalid number : color orange is not a color value : orange
* Line: 97 Context : .parser

Property error doesn't exist : }
* Line: 100 Context : .parser

Property m rgin doesn't exist : 2em
* Line: 100

Parse error - Unrecognized : };
* Line: 102 Context : .parser

Invalid number : width only 0 can be a length. You must put an unit after your number : 200
* Line: 103 Context : .parser

Parse Error - ! error;
* Line: 103 Context : .parser

Parse error - Unrecognized : }

.travel, hmmm and is meant for .travel agencies or for tourism boards... ok maybe this one could serve a purpose.

.xxx is stupid, it serves no point other than pointing out it's smut.

.asia, why the fuck does Asia need it's own TLD? Is it because there so huge? Or are asian countries domains too overcrowed

.mail why not just get better spam filters?

.mobi just points out it's a mobile phone company

.tel, there's two versions, you expect to type out a number that fucking long? The second, it seems the same, I dunno. Maybe this will serve some use.

.post, do postal authorites really need there own website, well then again. USPS gets an advantage. So I guess so.

.cat, why does a language get a domain, what next? .eng, .esp? Also, they could be abused by cat owners.

The proper solution is to use the named character entity references -- in this case ampersand + "eacute" + ; which will work regardless of the code page in use.

As refererence, I'd send you to the remarkable joelonsoftware article that explains why your approach fails to work in many cases:

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

...Slashdot editors do cliché posts too?

(Although it should probably be "Cell Phone as e-Book Reader...in Japan!")

Seriously, are these e-Books PDFs? If so I can probably write mine in XSL-FO, use FOP to make one of these, and then see my work on cellphones. That'd be sweet.

Google Maps used to work in Firefox, but for some reason it and Google Ride Finder no longer do (at least for me). Perhaps it has something to do with the page's 42 errors, implying it is not valid XHTML.

So use one of those things that tells you to type in the word in the box below, and it's all distorted with noise added to defeat character recognition algorithms

And blind people.