Slashdot Mirror

See "HTTP status codes": http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

The media and video elements are part of HTML 5, are implemented in the WebKit version on which Google Chrome is based, yet are disabled in Google Chrome. Same story for HTML 5's structured storage (local SQL database) support. Google Chrome has significantly worse support for HTML 5 than the WebKit version on which it is based, and thus, than the corresponding Safari release.

Please, look at the article I linked earlier before making any more comments. I implore you. You're getting into a bashing rampage and stepping on your own feet.

Chrome developer Darin Fisher says that while Chrome was under wraps, a few things had to go. Despite using the latest branch of WebKit (the same branch to be used in the next version of Safari), the local database features didn't make it into Chrome's first release. Unfortunately, the safety and performance factors of Chrome's isolated sandbox system, which enables faster and more secure browsing by partitioning tabs in memory and CPU process, would break the built-in WebKit database functionality.

I never said I liked Chrome. I'm on a Linux box and have no plans to try or install it on my machine when it becomes available.

Even with the response that the Google developer had given, the changes are just plain odd. It not only makes a lot more work integrating future versions of webkit, they have to keep their own proprietary, non-standard code up to date.

Having said that, using the word proprietary doesn't mean a lot when it comes to HTML 5. It's still just a draft. You did know that shining example that is webkit introduced the proprietary canvas tag. Later it was adopted in the HTML 5 drafts because it was that good. This is where a lot of the new features in W3C complaint HTML comes from. Mozilla has been doing their own thing with border radius for a while, and also have that incident with theora support in HTML 5.

Even if you write your code to be compliant with the current version of HTML 5, there is a good change it won't work 100% with the final version of HTML 5 when it is finished. The browser makers are taking the same gamble, except they may influence just what HTML 5 may turn out to be. You're playing with fire if you use HTML 5 in your websites right now.

By the way, did you know one of the two editors of the HTML 5 working draft is a Google guy?

As for the standards I'm somewhat suprised at your statement that it's not designed to allow for rendering pages identically. The standard is not written around browsers (which is what you imply if you understand the logic of your statement), it's written as THE standard.

I was not saying that the standard is written around browsers - it's not, and it shouldn't. And it does allow to render pages identically, of course, it just doesn't require it.

While it may allow for flexibility in certain situations it also provides design specific features and tools, such as table widths, border sizes, font sizes, typefaces, stylesheets and the like, all of which are designed to allow the "designer" to build a site that "should" display the way intended, when the standard is followed.

Not at all. For example, even if you set the font size in pixels, you have no way of knowing how precisely the character glyphs will be rendered, and this may vary the width of the text a lot (compare Firefox rendering text on Win32 and on Linux) - and there goes your pixel-perfect precision already. Not to mention that you cannot mandate the user to have any specific font on his system, and thus any CSS styles asking for a specific font are, at best, hints (and this is also explicitly covered by the standard). The same goes for box sizes. In fact, the CSS spec in its section covering conformance of user agents, also explicitly states that "values may be approximated when required by the user agent", without any limitation as to the scale of approximations. So a conforming text-mode user agent may approximate all pixel sizes to multiples of character box size, for example. Not to mention the interesting clause that says, "the inability of a user agent to implement part of this specification due to the limitations of a particular device (e.g., a user agent cannot render colors on a monochrome monitor or page) does not imply non-conformance".

In short, if you really think that HTML/CSS, as specified by W3C, gives you enough control over layout of the page to guarantee precise, pixel-perfect alignment and wrapping of text and elements on any given user agent, you're plain wrong. It never did, it does not do it now, and there are no plans to change it to do that.

That has always been a goal of improving HTML design capabilities into the standard, whether you want to believe it or not. If that wasn't the case the standard would simply be written to provide for the placement of image blocks and be done.

Actually, "placement of image blocks" would probably be quite enough for plain design. The whole complicated CSS thingy is there so that you can think about the information itself first, and then add design on top of it as an optional component that can be partially or fully disabled. If you want to see what I mean, go to the Opera web site, disable scripts and CSS, and look at what you see, and how a properly made web site should behave.

Remember you as a web developer don't dictate look and feel (even though many developers wish they could design). A web developer's job is to impliment the designers "design" into a website and make it 1) work and 2) be true to the design.

As a web developer, I never dictate look and feel to web designers. I just wish the web designers stopped trying to dictate their look and feel (to unreasonable levels) to the end users, myself included, especially in a media that is deliberately designed in such a way that makes it impossible, and tends to break when people try to force it to do what it cannot and is not supposed to be able to do (see my examples above).

Should screen resolution be limited to 320x240 so that subnotebooks and handhelds can run at the same resolution?

No. Web pages should scale, and that's what CSS @media rules are designed for. But unfortunately, the entire HTML gets sent to the device no matter what @media it uses.

Should games be forced to limit ther polgygons to something that can run on subnotebooks and handhelds?

If the developers don't design their product to scale down to handhelds, then owners of handhelds will buy the competitor's product that does scale down to handhelds. A lot of early PSP games earned poor reviews for their long loading times because the PS2 assets weren't scaled down properly.

People don't use Firefox on their iPhones

Only because of Apple's lockout chip. They use Safari, which is equally heavy for a reason: If we have completely separate code bases for the mobile and desktop browsers, eventually the two code bases will develop "quirks" (incompatible interpretations of a spec), or features will end up missing entirely from the mobile version. This has already happened with Windows Internet Explorer and Pocket Internet Explorer.

and they don't use the Treo browser on their desktops.

How should a small web developer test his web site against the quirks of PDA browsers without owning all makes and models of PDAs?

Doesn't the W3C already collaborate with the INRIA on a reference browser? http://www.w3.org/Amaya/

There is a reference implementation.

It's not bloated.

It doesn't do plugins...

Noone wants to use it...

I imagine the name of the group pushing a browser does help, but I'd suggest google start looking into third party addons for Chrome anyways. And non-window versions...

1. Real Life Comics sucks, it's the king of "talking head" and "copy-paste" comics. Read better comics. But on to objective matters:

2. Your browser sucks. http://www.reallifecomics.com/ sets an ETag for every page. After loading the page once and reloading, Firebug shows a string of 304 Not Modified responses.

Since the site also supports Keep-Alive stringing along a bunch of "not modified" requests shouldn't be a big deal. Firebug shows a load time of about 200ms for every cached resource. (500ms for the main page which isn't cached, 200ms for everything else.)

I suppose setting the "Expires" header could be even more cache-friendly, but you may want to check your browser's cache settings.

BTW if you have a personal stylesheet you should easily be able to say:

html, body, p, h1, h1, h3, h4, h5, h6 {
font-family: Arial, sans!important;
}

add in any additional tags you really want to override and voila... it's done.

CSS override priority goes like this:

user agent declarations
user normal declarations
author normal declarations
author important declarations
user important declarations

http://www.w3.org/TR/CSS21/cascade.html#cascading-order

It's really not that complicated

Regarding rendering issues... that's probably an artifact of your machines ability to antialias... on my mac I have no issues with serif fonts at sizes approximately 12px or larger (~11pt).... obviously everything looks better on a mac so YMMV

http://www.w3.org/2006/WSC/wiki/Glossary

It only works for user agents that handle JavaScript (which includes the major search engine spiders); the 301 redirect method on the other hand has been part of http specification from the beginning and is (anecdotally speaking) supported by just about every http client.

Why should you have to keep your links 'up to date'? They chose the domain name and the web address; nobody forced them to pick the one they did. It's the webmaster's responsibility to pick addresses that others can rely on. See Cool URIs don't change.

After all, what makes more sense: a single webmaster maintaining a logical address which you can always use to get the right information, or thousands of websites all over the net scrambling to 'update' their links at exactly the right moment?

The CTO of Opera is the guy that proposed the concept of CSS (Cascading Style Sheets). I think he's one of the ideal people to expect to deliver an unbiased commentary. http://www.w3.org/People/howcome/

What if I want a fancy title without using an image that screws over scalability (fluid layouts FTW) and screen reading software? Sane font usage could be good for design purposes.

But Scalable Vector Graphics already do that, sans the shitty and unnecessary DRM.

And who's the market here? Doesn't anyone else think it's weird to try to protect /shapes/? Did they also propose a standard for blocking screen captures? Or vision? How ridiculous some peoples fantasies about data protection are.

There are two issues here, that slashdot combines, and neither of them are DRM. First, characters not used on the page may be dropped from the font to save space - this isn't DRM, just a bandwidth saving measure. This is why the EOT fonts, if subsetted, must be regenerated if your site changed - while it may be annoying, depending on the implementation, there are no restrictions on the renderer, nor is this a required portion of the spec.

Second, there are embedding flags (EOT spec, 4.1). These are essentially a machine-readable copyright and license statement - it is absolutely trivial to manipulate this field. You could do it in a few dozen lines of code in the programming language of your choice, with no need to reverse engineer, drag out keys, whatever.

In short, nothing to see here. This slashdot article makes a big deal out of absolutely nothing.

If only we had some kind of Scalable Vector Graphic that would allow us to do logos and such, that was a W3C standard... ahhh, but to dream.

Why don't we worry about supporting existing standards, instead of making new ones that are useless?

See the Wikipedia article and the W3C team comment on the submission

http://en.wikipedia.org/wiki/Embedded_OpenType

http://www.w3.org/Submission/2008/01/Comment

"Or, should they encourage normal font files on the web and help break Microsoft's forgotten monopoly?" Gee, I wonder what /. will think...

It's interesting to note that the linked page has absolutely nothing to do with EOT; rather, it refers to Microsoft's Core Fonts for the Web.

Besides, this is quite old news - I certainly knew about it several months ago, and the submission website says it was submitted in March, over five months ago.

I've read the EOT spec. The DRM is trivally, hilariously bad:

This flag indicates that the FontData array and EUDCFotData array (if present) has been encrypted using an XOR algorithm using an XOR key of 0x50 on each byte of the font data. This happens on final data, after compression and subsetting. The font must be decrypted using the XOR key to accesses the font data.

In addition, whilst it is possible to embed only those glyphs needed, anyone who's using a CMS is realistically going to be embedding all the glyphs needed for the language anyway.

So why bother?

Actually, generated content is over a decade old.

I'm still not impressed. I don't care how many whizzy-gig features Microsoft adds to their browser. It is still useless to developers until Microsoft installs standards support. And by standards support, we don't just mean fixing the broken setAttribute method. How about supporting a fucking decade old standards?!? Nope, still no mention of it. In fact, the bug on the issue was "closed by design".

By design? By fucking design?!?! BULLSHIT. Microsoft does not want to be interoperable with other Web Browsers. Period. If Microsoft really wanted to turn around their image in the market, they can start with something as stupidly simple as supporting addEventListener, removeEventListener, and dispatchEvent. I don't even care if the code looks like this:

Element.prototype.addEventListener = function(name, callback, capture) { attachEvent("on"+name, callback); }

^That's fucking WRONG and it would STILL be an improvement!

Microsoft can take their God damn browser and shove it where the sun don't shine for all I care. They have shown such incredible disdain for their customers, that I have to wonder why their even trying to hide it from the market.

*DEEP BREATH*

Microsoft, you are transparent. Your juvenile attempts at lock-in are NOT working and will NOT work. All you're going to do is piss off the people recommending software to grandma, grandpa, mom, dad, sisters, cousins, next door neighbors, school teachers, bosses, subordinates, government agencies, etc. IE will continue to lose market share. It won't be much longer before the alternative browsers reach critical mass. Many websites already show Firefox maintaining parity or even surpassing Internet Explorer. If you actually want to WIN the market, try competing for a change!

Can I get an AMEN?

It doesn't get CSS generated content images right. That's four years old and all other modern browsers can do it. Bah.

SOAP (Simple Object Access Protocol)

Actually no: since SOAP version 1.2 SOAP is not an acronym anymore because it has nothing that is "simple".

All my webpages validate as xhtml strict, and placing the tag in is the only way for it to validate.

Sorry, but you're incorrect. The applicable block of valid XHTML, with the Google Analytics code where Google advises to put it:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

[snip]

<script type="text/javascript">
//<![CDATA[
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write("\<script src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'>\<\/script>" );
//]]>
</script>

<script type="text/javascript">
//<![CDATA[
var pageTracker = _gat._getTracker("UA-3044339-1");
pageTracker._initData();
pageTracker._trackPageview();
//]]>
</script>
</body>

Posting anonymously, because I don't want to waste the moderation points that I've already applied to this thread.

Why the fuck should a document markup language specify required codecs?!

It doesn't need to. It should specify recommended codecs to make the situation of The Article less likely to arise.

HTML 4 doesn't even specify any image formats required for the IMG tag.

W3C maintains a copy of the PNG specification as a Recommendation. It also maintains an informational web page about JPEG and JFIF. Where are the corresponding pages for audio and video formats?

If they were to force required codecs, text-only browsers would be required to support video

That's why I said SHOULD and not MUST, as in "user agents that implement streaming video and audio SHOULD be able to decode Ogg Theora and Ogg Vorbis."

and that's just ludicrous.

I'm glad you didn't misspell it :-)

Why the fuck should a document markup language specify required codecs?!

It doesn't need to. It should specify recommended codecs to make the situation of The Article less likely to arise.

HTML 4 doesn't even specify any image formats required for the IMG tag.

W3C maintains a copy of the PNG specification as a Recommendation. It also maintains an informational web page about JPEG and JFIF. Where are the corresponding pages for audio and video formats?

If they were to force required codecs, text-only browsers would be required to support video

That's why I said SHOULD and not MUST, as in "user agents that implement streaming video and audio SHOULD be able to decode Ogg Theora and Ogg Vorbis."

and that's just ludicrous.

I'm glad you didn't misspell it :-)

Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.

That's what DOM Range and DOM Selection are for. These are implemented by Gecko, Opera and Safari. IE has an alternative implementation that can do pretty much the same thing. Also, there's the document.execCommand() method for modifying rich text areas if you don't wanna write your own custom logic for making bold text or converting paragraphs to lists. There's no concrete standard on execCommand() yet but all popular browsers support it with a common set of commands.

If you say rich text editing in JavaScript is hard and can use much room for improvement, then I'd agree with you. But saying that such functionality does not exist, is wrong. There's enough misinformation everywhere about JavaScript as it is.

Yeah, because if you don't develop to standards, nobody will use your website.

HTML5 comes in two flavours. One is straight HTML5 which is based off HTML4 (same parsing rules), the other is XHTML5 which is strict XML and requires the application/xml content type. None of them are really related to XHTML2 which is mostly dead at this point.

HTML5 comes in two flavours. One is straight HTML5 which is based off HTML4 (same parsing rules), the other is XHTML5 which is strict XML and requires the application/xml content type. None of them are really related to XHTML2 which is mostly dead at this point.

Pssssst... Hey! Ever hear of character entities?

You know who's behind W3C, do you?
It's a committee of companies. And Microsoft is one of the big fishes in there. (Primarily responsible for blockings and intrigues.)
Here's the complete list: http://www.w3.org/Consortium/Member/List

I understand your desires, for mine are the same. I think 90% of it would be solved if their was greater native browser support for SVG & SMIL.

You should probably stop reading /. in that case

http://validator.w3.org/check?uri=http%3A%2F%2Fpolitics.slashdot.org%2Farticle.pl%3Fsid%3D08%2F08%2F16%2F1748246%26from%3Drss&charset=(detect+automatically)&doctype=Inline&group=0

I would respect it more if the html (or xhtml in this case) would be actually valid. It is not even close.

54 errors:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fseantevis.com%2Fkansas%2F3000%2Frunning-for-office-xkcd-style%2F

A quick scan of TFA doesn't reveal the heritage of Aurora, but the emphasis on web publishng vs viewing, and even the name, both immediately bring to mind the (ancient, but continuously updated) W3C editor/browser Amaya:

http://www.w3.org/Amaya/

Well, the ultimate CSS reference is obviously the spec itself: http://www.w3.org/TR/CSS21/

Isn't the ultimate reference the definition?

http://www.w3.org/TR/CSS21/

http://www.w3.org/Style/CSS/

Isn't the ultimate reference the definition?

http://www.w3.org/TR/CSS21/

http://www.w3.org/Style/CSS/

A quick read of the web's history, such as the Tim Berners-Lee book Weaving the Web, and you'd *learn* that the first web browser was, in fact, open-source.

Actually, a quick read says "Despite persistent rumors to the contrary, however, Mosaic was never released as open source software during its brief reign as a major browser; there were always constraints on permissible uses without payment." And in any case, Microsoft licenced the code from Spyglass which had licenced it from Mosaic. Presumably, there was payment.

Neither the web browser or tabbed browsing originate from open source projects.

False. Somewhere around here I've still got a spool with a copy of the NCSA server and Mosaic sources from way back when. And lookee here, you can still download Mosaic source for X Windows, version 1.2 in the directory called 'old'.

A quick read of the web's history, such as the Tim Berners-Lee book Weaving the Web, and you'd *learn* that the first web browser was, in fact, open-source.

That's what the internet was founded on, open principles, not proprietary, though proprietary wasn't ever excluded. Much of the internet's infrastructure was proprietary early on, and still is. But if you're going to assert that open source software is nicking code and patents from proprietary, let's see some evidence, eh?

Don't know about tabbed browsing, though it's plain for anyone to see that MS was late to that party, and brought with it a very clunky implementation.

I'm all for native audio and video support in browsers, but now that we're starting to surf on netbooks, mobiles and toasters wouldn't it be great if the spec also included a way to determine wether or not the user actually wants this content to play? Automatically, or at all? Or if they want it to shut up so they can surf without their music-playlist being blarred over? Note that the intention of the user in this regard is a seperate issue to wether or not the device or connection is capable of supporting said media. Maybe I'm just being stingy with my precious clock cycles...

http://lists.w3.org/Archives/Public/public-html-comments/2008Jul/0000.html

captcha: cameras

http://www.w3.org/QA/2007/12/when_will_html_5_support_soone.html

What W3C specification exists for a Javascript drawing API?

HTML5. Which is itself a W3C dump of the ongoing work over at the WHATWG. Here's the specific W3C text on Canvas:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.

When authors use the canvas element, they should also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content.

In interactive visual media, if the canvas element is with script, the canvas element represents an embedded element with a dynamically created image.

In non-interactive, static, visual media, if the canvas element has been previously painted on (e.g. if the page was viewed in an interactive visual medium and is now being printed, or if some script that ran during the page layout process painted on the element), then the canvas element represents embedded content with the current image and size. Otherwise, the element represents its fallback content instead.

In non-visual media, and in visual media if the canvas element is without script, the canvas element represents its fallback content instead.

The work over at the WHATWG is a collaboration between Mozilla, Opera, and Apple. Microsoft was offered to contribute, but they declined. (Though a few Microsofties have been seen on the mailing lists as of late.)

What W3C specification exists for a Javascript drawing API?

HTML5. Which is itself a W3C dump of the ongoing work over at the WHATWG. Here's the specific W3C text on Canvas:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.

When authors use the canvas element, they should also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content.

In interactive visual media, if the canvas element is with script, the canvas element represents an embedded element with a dynamically created image.

In non-interactive, static, visual media, if the canvas element has been previously painted on (e.g. if the page was viewed in an interactive visual medium and is now being printed, or if some script that ran during the page layout process painted on the element), then the canvas element represents embedded content with the current image and size. Otherwise, the element represents its fallback content instead.

In non-visual media, and in visual media if the canvas element is without script, the canvas element represents its fallback content instead.

The work over at the WHATWG is a collaboration between Mozilla, Opera, and Apple. Microsoft was offered to contribute, but they declined. (Though a few Microsofties have been seen on the mailing lists as of late.)

I don't think I'm understanding what this is. What W3C specification exists for a Javascript drawing API?

HTML 5

I don't want Firefox embracing and extending web protocols. The other changes are in line with W3C specs, but this sounds like a cool whizzbang thing that developers might like. I don't want that stuff in there. If you want a drawing API, use Flash, or Java, or something else.

Thankfully, we don't have uninformed luddites like yourself on the development staff

MathML does not seem to be a step in the right direction to me. I'm a card carrying mathematician who has to use LaTeX for papers (although I tend to use it for lectures, presentations and so on, since like the original poster, nothing seems to be available that is better). Latex 3 seems to occupy the same mythology as Duke Nukem Forever.

Whatever problems exist in LaTeX (and there are many), it has one huge strength - it is essentially trivial, after a little practice, for a human to type maths straight into LaTeX format. For this reason discussions in email or within maths mailing lists are often conducted in TeX or LaTeX fragments.

On the other hand, MathML was never designed to be easily human writable, and when I read that years ago, I immediately lost interest - what's the point? When you're typing huge amounts of maths, any sort of helper equation editor is a complete PITA. The irony that the WWW, design by scientists for scientists at its inception sucks so much at rendering mathematics cleanly is never lost on me. If MathML sucks on the web, I guess it sucks for documents too.

MathML is pretty full featured. Equations are stored in a standardized XML format.

http://www.w3.org/Math/

Really?

Wikipedia has a great example on why MathML (or XML in general, rather) isn't that great. At all.

Following is the quadratic formula in LaTeX:

x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}

Now, in MathML:

BEHOLD! No, it's not the first code sapmle. It's not the second or third either.

(/. didn't allow me to post the monster here)

Let the hate commence. Anyway:

XSL-FO is another markup language, but there's a good bit going for it, not the least of which is an application that renders it directly to PDF: http://xmlgraphics.apache.org/fop/

The main good thing about FO is the ability to take advantage of related XML technologies to help you generate the documents (and the various tools that you can use to generate them). You can embed SVG diagrams and MathML if you're comfortable with the namespaces; FOP can definitely render SVG via Apache's Batik project (which is also very good) and I'm pretty sure will also render inline MathML via an optional plugin. A lot of people mentioned OpenOffice, and the cool thing there is that since the documents it generates are XML documents (I'm pretty sure its equation editor emits MathML), you can use XSLTs to transform the documents that it generates into XSL-FO documents for rendering.

The obvious missing feature is the WYSIWYG app, but you'll find a bunch of links at the W3C's XSL-FO site.

Anyway, like I said, let the XML hate commence.

C

MathML is pretty full featured. Equations are stored in a standardized XML format. http://www.w3.org/Math/

Don't forget the event handler.

He didn't. The DOM includes events.

....For people to use the @$#%#$^ing international standard for date.

http://www.w3.org/QA/Tips/iso-date
http://en.wikipedia.org/wiki/ISO_8601

Now, its certainly true that every webdeveloper has done their own date pattern. Which proably gets leap years _almost_ right. And I can't see a problem with adding a w3c supported common form.

But I'd rather have SVG support.