Slashdot Mirror

I'm not a Web standards maven, but I thought that whereever iframes originally came from, they were now a completely legitimate part of the W3C HTML standard. If so, then they ought to work with anything. The description in the HTML 4.01 standard seems to be here, and as a non-language-lawyer it seems to me that it is supposed to work unless your "user agent" (browser) does not support frames.

If Google is intentionally doing something makes properly formed, Web-standard HTML not work properly, then shame on them. This isn't a question of "reciprocating" or "not reciprocating," it's a question of following Web standards or not. It's bad enough when a company is just too lazy or careless to follow them, but if a company intentionally makes proper HTML not work, I think that qualifies as "evil."

My browser doesn't do hyphenation or ligatures, the kerning is probably rather bad, and I don't think that the line breaking algorithm is as good as the one in TeX.

Hyphenation is part of the CSS3 draft standard, and is supported by all WebKit browsers and Firefox in one form or another (-webkit-hyphens: auto; -moz-hyphens: auto; hyphens: auto;).

Ligature support is normally part of the OS's type rendering system, and should be used automatically if the font contains the ligatures and if they are properly specified in the font. If they aren't, assuming you already create a JavaScript rendering engine with some sensible text callbacks built-in, it would take only one line of JavaScript to perform the necessary text substitution. And if you want manual control, as long as you use the UTF-8 character set for your HTML content, you can forcibly insert a specific ligature in a particular spot by inserting the right UTF-8 character code instead of the code for the letters that make it up.

Kerning is a matter of your OS's type rendering system, so if you're using an OS that actually understands all those OpenType kerning things, it should do very nearly the same job as XeLaTeX. If it doesn't, get a better OS.

Moreover, there is no reasonable way to set the line length (half of the websites use a very small column, and the other half use the full window width which is generally too wide), and making a table of content is a pain in the ass.

That's not really that relevant to using a specific engine (e.g. WebKit) as a typesetter (which is what I was talking about). What you're talking about is inconsistencies in the way different sites design their content. Now, LaTeX might make two-column content easier, I'll admit, but outside academic papers (for which LaTeX works reasonably well) and newspapers (for which layout is, by necessity, done by hand), that's not exactly a common layout style for publishing.

LaTeX really doesn't have a very good way to say that the end-of-section marker must be on the same page as at least two lines of the previous paragraph

I't called a widow, and you can prevent them with \widowpenalty=10000. By default, they are only discouraged because sometimes they look less ugly that the other alternatives.

No, that's not a widow. A widow penalty tries to ensure that you don't get the last line of the paragraph by itself on the next page. LaTeX provides no equivalent functionality for saying that the line of content after that paragraph (e.g. a \vspace followed by a centered *** section mark) may not be by itself. Nor, AFAIK, does LaTeX provide a way to avoid what I would call widow paragraphs (an entire one-line paragraph appearing by itself) because it renders content a paragraph at a time. As far as LaTeX is concerned, that isn't a widow because the entire paragraph appears on the page.

And while we're talking about LaTeX issues, I forgot one really nasty one that caused all sorts of problems for me. LaTeX doesn't handle UTF-8 very well at all. By default, it inserts no wrapping around the em dash. I ended up adding code to the XSLT that I'm using to produce the LaTeX markup so add a hair space after the em dash, which LaTeX then happily treats as a word break. Prior to that, I was getting the most horrendous overfull and underfull hbox problems I've ever seen whenever an em dash appeared near where a line should break....

The best solution would be to permit column-type text flow

And apparently, this Candidate Recommendation for an extension to CSS agrees with you. One wrinkle is that the elements on a page might need to be reordered to fit the CSS flow model to any given screen width.

But that is exactly what he is proposing. As far as I can tell, the server won't even know what "flavor" of the page is going to be displayed anymore than it knows whether the print or screen CSS stylesheet is being used now.

In Lie's ideal world, a Web page could come with different CSS formatting code, then show the paged version when appropriate. The HTML, though, which describes things like text and graphics, would be fixed.

Already exists, and already supported by Webkit. Firefox has a similar, but proprietary, interface.

CSS is NOT here to do page layout.

Perhaps not in the days of nested tables, but CSS has grown up since then, and absolutely can be used to do page layout.

CSS is the language for describing the presentation of Web pages, including colors, layout, and fonts.

From http://www.w3.org/standards/webdesign/htmlcss (emphasis mine)

Ah, and thank you for the "old" qualification, and the assumption that I can't adapt nor can I see anything better than my old habbits. Basically, you're calling me grandpa and patting me on the back. Do you even see how rude and incredibly stupid that is?

Old folks are often also reticent to take their stress meds, and so don't notice emoticons indicating the tone of jibes. :P

Please answer this question honestly: How old are you?

38. I don't see how it's relevant though. And I've been building website professionally for the last 15 years.

I ask merely because your comments come off as if written by somebody who is 12 or 13 years old, and who thus missed out on experiencing a large portion of the WWW's history.

Like others have pointed out, changing the content you're serving based on the User-Agent header value has always been a bad practice, and should be avoided. Every experienced web developer knows this.

Contrary to what you say, the User-Agent header was not originally meant to be used as you describe. Some of the earliest attempts at creating specifications, such as those from 1992 found at http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#user-agent, clearly state that it was meant purely "for statistical purposes and the tracing of protocol violations." Neither of those advocate, nor even suggest, that the response should be modified depending on the header value.

Point taken, I wrote too fast.

Furthermore, you have clearly misunderstood the purpose of the WWW. It's a system for delivering documents that can link to one another. It is not about creating "UIs", like you mistakenly appear to believe.

A document is displayed to the user through a UI. Printing is on paper is a form of UI. Displaying it on a screen is a form of UI. By saying you don't need a UI, you're saying that you don't need the users to view your document.

When used properly, the exact same content should render perfectly fine on all sorts of devices with a wide range of capabilities and display media.

There's fine, and there's nice, which is pleasant to use. I guess your websites all look black & white (account for BW printers) with no images (account for Lynx users) and just Hn, b, u, i tags. And even those are bad. strong, em, quote should be used instead. Talk about living in the 20th cetury.

It's only when you misuse the WWW that you start running into the problems that you describe, and have to start attempting the horrible practices that you advocate. Indeed, different devices do need different UIs. The only tenable solution to that problem is to create separate native applications.

There are other options that work perfectly well. It's your right to choose not to use them of course. I respect that, contrary to you who disrespect what I do without actually knowing what I do for that matter. And you don't even want to know apparently.

All attempts at providing cross-platform UIs have failed,

For you.

regardless of who developed the technology, which platforms were targeted, and when it was attempted. Trust me, you won't succeed any better than they did, and will likely produce a result that is far worse.

Thanks for the tip. I have websites that work fine for years serving a smaller Logo to iPhones because, you know, they're slower devices with smaller screens. I guess that's a failure and my iPhone users should see a huge logo that takes forever to load. Or my desktop users should see a 100px by 50px logo. Because you said so.

Please answer this question honestly: How old are you?

I ask merely because your comments come off as if written by somebody who is 12 or 13 years old, and who thus missed out on experiencing a large portion of the WWW's history.

Like others have pointed out, changing the content you're serving based on the User-Agent header value has always been a bad practice, and should be avoided. Every experienced web developer knows this.

Contrary to what you say, the User-Agent header was not originally meant to be used as you describe. Some of the earliest attempts at creating specifications, such as those from 1992 found at http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#user-agent, clearly state that it was meant purely "for statistical purposes and the tracing of protocol violations." Neither of those advocate, nor even suggest, that the response should be modified depending on the header value.

Furthermore, you have clearly misunderstood the purpose of the WWW. It's a system for delivering documents that can link to one another. It is not about creating "UIs", like you mistakenly appear to believe. When used properly, the exact same content should render perfectly fine on all sorts of devices with a wide range of capabilities and display media.

It's only when you misuse the WWW that you start running into the problems that you describe, and have to start attempting the horrible practices that you advocate. Indeed, different devices do need different UIs. The only tenable solution to that problem is to create separate native applications. All attempts at providing cross-platform UIs have failed, regardless of who developed the technology, which platforms were targeted, and when it was attempted. Trust me, you won't succeed any better than they did, and will likely produce a result that is far worse.

Indeed, they're not even using the HTML 5 Doctype, it's XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Sadly, it's not quite that simple. That doctype tag thinger is what the HTML5 spec calls an "obsolete permitted DOCTYPE string" for HTML5 documents. Obviously, I object to that; I want to use, say, XHTML 1.0 and not any worse usurper "standard", and the former is not "obsolete" except by plan.

and I don't see any HTML5 markup in the page (for instance, they use

instead of the semantically correct HTML5 <header>).

I don't think that not using new "HTML5" tags makes a doc non-HTML5, but they say div* is best used "when no other element is suitable" so your complaint seems about right.

What they mean is they dropped Flash video, they're clearly highly confused about what HTML5 actually is.

Hakuna matata; HTML5 seems confused about what HTML5 actually is sometimes. I probably used HTML5 by accident when I prayed to the gods for its slow, painful death.

*It took me a few minutes to check that div was even part of HTML5. Damn its badly written Elements section.

Indeed, they're not even using the HTML 5 Doctype, it's XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Sadly, it's not quite that simple. That doctype tag thinger is what the HTML5 spec calls an "obsolete permitted DOCTYPE string" for HTML5 documents. Obviously, I object to that; I want to use, say, XHTML 1.0 and not any worse usurper "standard", and the former is not "obsolete" except by plan.

and I don't see any HTML5 markup in the page (for instance, they use

instead of the semantically correct HTML5 <header>).

I don't think that not using new "HTML5" tags makes a doc non-HTML5, but they say div* is best used "when no other element is suitable" so your complaint seems about right.

What they mean is they dropped Flash video, they're clearly highly confused about what HTML5 actually is.

Hakuna matata; HTML5 seems confused about what HTML5 actually is sometimes. I probably used HTML5 by accident when I prayed to the gods for its slow, painful death.

*It took me a few minutes to check that div was even part of HTML5. Damn its badly written Elements section.

Indeed, they're not even using the HTML 5 Doctype, it's XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Sadly, it's not quite that simple. That doctype tag thinger is what the HTML5 spec calls an "obsolete permitted DOCTYPE string" for HTML5 documents. Obviously, I object to that; I want to use, say, XHTML 1.0 and not any worse usurper "standard", and the former is not "obsolete" except by plan.

and I don't see any HTML5 markup in the page (for instance, they use

instead of the semantically correct HTML5 <header>).

I don't think that not using new "HTML5" tags makes a doc non-HTML5, but they say div* is best used "when no other element is suitable" so your complaint seems about right.

What they mean is they dropped Flash video, they're clearly highly confused about what HTML5 actually is.

Hakuna matata; HTML5 seems confused about what HTML5 actually is sometimes. I probably used HTML5 by accident when I prayed to the gods for its slow, painful death.

*It took me a few minutes to check that div was even part of HTML5. Damn its badly written Elements section.

I'm not talking about 'web apps', I'm talking about mobile phone apps that do not require server access to function.

http://diveintohtml5.org/offline.html

* lets you access hardware (microphone, camera, gps, accelerometer)
> Not all of them, quite yet (geolocation yes, camera .. probably in the near future)
  > http://www.w3.org/TR/2010/WD-media-capture-api-20100928/ - Camera API - Google have said it will arrive in future Android versions
  > http://diveintohtml5.org/geolocation.html

* lets you manipulate a client-side database
  > http://diveintohtml5.org/storage.html - WebSQL

* lets you establish a socket connection to a server
  > websockets, ajax calls :)

Ideally, it'd be done with an application cache that keeps the gigabytes of data on the device. But the spec leaves quota expectations undefined, and real-world devices have been seen to have maximum cache sizes such as 5.25 MB that would be impractically small for this use.

TFTY

I'd love to see how they handle streaming gigs worth of game data over a browser every single time every single person wants to play a game.

Ideally, it'd be done with an application cache that keeps the gigabytes of data on the device. But the spec leaves quota expectations undefined, and real-world devices have been seen to have maximum cache sizes such as 0.005 GB that would be impractically small for this use.

PDF should not be a distribution method for online documentation or viewing in web browsers, it should be available as a tertiary format FOR PRINTING ONLY

Web browser developers have treated CSS paged media as a mere afterthought. What's the best practice to distribute paged media such as slide presentations for on-screen viewing?

Flash should not be the default video player. But it is.

I agree for pixel-based video, not so much for vector-based cartoons, at least until 2014 when Windows XP dies (taking IE <= 8 with it) and until browsers' SVG renderers become much faster.

Americans With Disabilities Act, not American Dental Association

Reminds me of a web-design instructor in highschool who was real big on trying to make one's sites disabled-accessible. For instance, make the site decipherable and navigable by screen readers for the blind

http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
http://www.w3.org/WAI/

That it's related to backwards compatibility has to do with vlm's point AFAIK.

Americans With Disabilities Act, not American Dental Association

Reminds me of a web-design instructor in highschool who was real big on trying to make one's sites disabled-accessible. For instance, make the site decipherable and navigable by screen readers for the blind

http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
http://www.w3.org/WAI/

That it's related to backwards compatibility has to do with vlm's point AFAIK.

To be even fairer, IE8 from 2009 on my up-to-date Windows Seven PC has no problems rendering properly

To be honest IE8 from 2009 on my up-to-date Windows Seven PC has no problems rendering broken code.

There - fixed that for you.

HTML5, which by design, gives unfettered access to certain storage areas, etc on your system via your browser.

Unfettered how? I thought access through <input type="file"> was limited to files that the user chose through an "Open" or "Save As" file chooser dialog presented by the system. From the File API spec: "The user is notified by UI anytime interaction with the file system takes place, giving the user full ability to cancel or abort the transaction. The user is notified of any file selections, and can cancel these. No invocations to these APIs occur silently without user intervention."

The phone icon is a universal symbol that's been around since at least 1996. While Apple did apply for a trademark on it in 2010, the pre-existing use of the symbol I've linked to I think pretty clearly invalidates the trademark. Unless you're somehow claiming nobody else is allowed to color their phone symbol green (the internationally recognized color for go).

Look at this phone: What do you see on one of the buttons? Correct: A green phone receiver icon. And it cleary predates the iPhone.

The phone icon is a universal symbol that's been around since at least 1996. While Apple did apply for a trademark on it in 2010, the pre-existing use of the symbol I've linked to I think pretty clearly invalidates the trademark. Unless you're somehow claiming nobody else is allowed to color their phone symbol green (the internationally recognized color for go).

Look at this phone: What do you see on one of the buttons? Correct: A green phone receiver icon. And it cleary predates the iPhone.

The phone icon is a universal symbol that's been around since at least 1996. While Apple did apply for a trademark on it in 2010, the pre-existing use of the symbol I've linked to I think pretty clearly invalidates the trademark. Unless you're somehow claiming nobody else is allowed to color their phone symbol green (the internationally recognized color for go).

The phone icon is a universal symbol that's been around since at least 1996. While Apple did apply for a trademark on it in 2010, the pre-existing use of the symbol I've linked to I think pretty clearly invalidates the trademark. Unless you're somehow claiming nobody else is allowed to color their phone symbol green (the internationally recognized color for go).

Though if it's simple games I don't see why they shouldn't be web apps.

Probably because web applications don't run on zero bars of signal unless they're tiny enough to fit into the storage limit for the device's application cache, which on an iPad appears to be as small as 5 MB. A passenger with a Wi-Fi tablet in a vehicle has no Internet connection but can still run native applications.

Something like polyglot markup? http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html This relies on the fact that XHTML markup is actually valid in HTML5. It may have taken them seven years to catch up with you, but they're there now. ;)

I'm pretty sure that I could use inline SVG with Firefox 3. Also, O'Reilly's SVG Essentials (2002) mentions using inline SVG. And even if the images were imported rather than inline, the markup would be the same and would be readable by screen readers.

See also http://www.w3.org/TR/XHTMLplusMathMLplusSVG/

Implementations and specifications have to do a delicate dance together. You don't want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don't want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is an unavoidable tension here, but we just have to muddle on through.

-Mozilla Developer
http://lists.w3.org/Archives/Public/public-html/2010Jan/0107

This is a perceptive quote which too many developers forget. Stop whining. HTML5 provides many new features that are necessary for modern web applications. It also standardizes many features of the web platform developers have been using for years. HTML5 is simply the first attempt to formally document the plethora of "standards" that web browsers have supported for over a decade.

Like/Believe it or not, HTML5 is a positive direction and one I'm glad is finally upon us. You just sound like a grumpy old programmer who doesn't want to accept things are changing. I've been stuck in browser-incompatible-hell for 12 years and we're finally at the beginning of a time when there is healthy browser competition surrounding who can implement the standards the best. I can't think of a more positive thing in my entire web development career. So, stop whining and get over it already.

It sounds to me you've just run into the dipshits that write articles about XML and basically make it as difficult as humanly possible so they sound smart. If your a C++ programmer try this. Write a DTD (make up your own XML). Then use the dtd to xsd script from here to create an xsd. Then use this to create C++ templates from the xsd.

If your working on a really big complex project that needs to have the ability to manipulate the output using C++, or even javascript in a browser, you will see how much of a time saver XML can be.

XML/XHTML was written for the parsers. HTML5 was written for web developers.

I'm a web developer who was also a member of the W3C's HTML Working Group (the group where the HTML5 spec was hammered out) during the development of HTML5, and I can tell you that if you believe that HTML5 was written for web developers, you are wrong. HTML5 was written by and for browser vendors -- Google, Apple, Mozilla, Opera, and (somewhat) Microsoft. The opinions of other Web stakeholders were of minimal concern. Concerns about the spec raised in the WG by anyone who wasn't a browser implementer were routinely shouted down with threats to withdraw from the W3C process completely by those who were. Some who advanced concerns, like accessibility professionals, were actually derided in quite personal terms by representatives of the browser vendors, both in official WG communications and in their own private back channels (like IRC), which invariably leaked. (Here's a good writeup of some of the friction that existed in the WG between browser vendors and everybody else.)

There are a lot of things in HTML5 that I'm looking forward to being able to use, but if you're a web developer you shouldn't kid yourself into thinking that HTML5 was written for you. It wasn't. Almost every decision made in the development of HTML5 was made to make Google's life easier, not yours.

A large part of the reason HTML 5 was written at all was to standardize large parts of the behaviour in web browsers that the web relies upon --- until a few years ago, huge parts of the budgets for browsers were spent on reverse-engineering other browsers (latterly IE6, before than NN4, etc.), which resulted in a hugely anti-competitive environment. When work on HTML5 started, it was incredibly hard to write a browser that worked with the vast amount of already deployed content, and what specs there were were practically useless, in part because the vast majority of content on the web doesn't follow them. Sure, you could refuse to support anything that isn't conforming, and "point out they're shit" as you so eloquently put it, but when Google doesn't work, nobody would care about your browser, and use one that does support invalid content.

HTML5's raison d'Ãtre is implementation interoperability, and when you have interoperability between implementations, you then have a hard time defining what should be conforming content and what shouldn't be --- both types of content are processed interoperably. As it is, what is conforming and what isn't has been based largely upon use-cases provided to the WG. If you think something should be changed in the spec, send feedback! mailto:public-html-comments@w3.org is the address! If you do send feedback, do make sure to include justification for whatever change you propose.

Also, what are these comment tags you refer to? ? Supported by old versions of a single-browser (IE is the parser used by both http://validator.nu/ and (through a programmatic transformation to C++) Gecko, and provides support for SAX, DOM, and XOM APIs. provide a Python implementation that offers a drop-in replacement for XML parsers in most Python XML toolchains.

Such tools, that finally offer good compatibility with existing content, combined with changes in the spec to try and unify HTML and XHTML further (if the XML syntax were so discouraged, why would there be efforts put into unifying them?), such as HTML parsing HTML elements into the HTML namespace, should make it entirely feasible for toolchains based upon XSLT and the like to use HTML input/output.

The whole living standard debate is one where I think many have missed the point: the a look at something like CSS, especially Level 3. Many drafts have multiple implementations, and implementations will continue to evolve over time, and move on to Level 4 drafts as soon as they appear, so what meaning does whatever you call "Level 3" have when people are only interested in implementing the latest drafts?

I think you have just invented MathML.

The spec is still a draft.
So if you start building websites with an unfinished spec, dont be surprised when/if it may break between browsers.

I may be just old, but I remember how I behaved when the draft of HTML4 was released.
Nothing much has changed with newbie-hyper-keen information leeches trying to bleed themselves on the edge of browser tech.

now get off my lawn.

Thanks. First part seems to be about Offline Web applications (in draft phase), which I understand should be supported by FF 3.5+. Not sure why the failure. The second part is definitely Web Database code, which is not HTML5, only exposed by Webkit browser. The proposed standard is actually Indexed Database API.

Thanks. First part seems to be about Offline Web applications (in draft phase), which I understand should be supported by FF 3.5+. Not sure why the failure. The second part is definitely Web Database code, which is not HTML5, only exposed by Webkit browser. The proposed standard is actually Indexed Database API.

Considering that the spec is not finalized, why are you so surprised that browsers are't done implementing it all yet?
The 11th draft of HTML5 was released this month http://dev.w3.org/html5/spec/Overview.html

If WebKit would support textArea (SVG Tiny 1.2) the applications I write would work on any device using it. eg. They would scale to any screen size. As a result they would have more applications to list.

And I don't really trust an organization like Mozilla to be able to create something that meets the needs of most people. Their staunch opposition to H.264 is a prime example of this. H.264 is an non-negotiable requirement for me. If you won't support it, I can't use your product. Period.

Then the Web is not for you. It isn't some kind of Mozilla standard that Mozilla is worried about, it's Web standards. Most Web software developers disagree with the idea that closed, royalty bearing formats are an acceptable choice for the Web. Mozilla, as we know, disagrees with you. The W3C disagrees with you. Opera disagrees with you. Google disagrees with you. And Tim Berners-Lee, of course, disagrees with you.

If graphics and equations were required, I would have moved to a generic HTML + css method.

Most web browsers that I've seen are based on the model of rendering a web page to a scroll that is 960px wide by infinitely tall. But in the real world of print, the codex has replaced the scroll. The paged media module in CSS3 is still only a Working Draft. So which web browser would you recommend that has thorough support for MathML and for CSS paged media?

We have about a 120 degree field of view.

But how much of this field of view does your monitor occupy? CSS specifies the standard viewing distance for a desktop PC monitor as 28 inches, meaning a 21" 16:9 PC monitor has only 36.2 degrees. (Showing my work: 21" diagonal VIS * 16/sqrt(16^2+9^2) = 18.3" wide. Horizontal field of view is 2*arctan(width/2/distance), or 36.2 degrees.)

Doing that would be a bit surreal. It would be a game that looked as though you were looking through a window into another world the entire time. Which would be kinda neat, but it is a bit better if you get more of a view of the world at all times so that you feel like there isn't a monitor.

We have about a 120 degree field of view.

But how much of this field of view does your monitor occupy? CSS specifies the standard viewing distance for a desktop PC monitor as 28 inches, meaning a 21" 16:9 PC monitor has only 36.2 degrees. (Showing my work: 21" diagonal VIS * 16/sqrt(16^2+9^2) = 18.3" wide. Horizontal field of view is 2*arctan(width/2/distance), or 36.2 degrees.)

Here are 34 bugs for you just on the home page. http://validator.w3.org/check?uri=facebook.com&charset=(detect+automatically)&doctype=Inline&group=0

If you'd like to help out against Apple (on a different matter), the W3C is looking for prior art on a couple of Apple patents.

This is not about making more money. Mozilla is not driven by that economic model. Mozilla sees the walled gardens of the current crop of smartphone and similar devices operating systems as a threat to personal freedom and the heath of the internet. This project is an exploration partly to see what technical gaps exist that web application needs access to function in a similar manner to a desktop application.

There are already companies and working groups trying to accomplish this. Rather than have the specs written without any exploratory work. Mozilla is proposing to build out B2G to evaluate where those problems and shortfalls are. To me this seems like a better idea than having device manufacturers who want to expose the world. Is the user on 4g, wifi, what is the access point name, what is the user paying per kb, etc.? Or having working groups building out a spec absent of actual web developers.

They have to take the same acronym as a 20+ year old file format for storing numbers?

It's almost like they didn't bother putting the term 'CDF file' into a search engine to see if anyone else was using that acronym already for a file extension. (of course, w3 even used it twice)

They have to take the same acronym as a 20+ year old file format for storing numbers?

It's almost like they didn't bother putting the term 'CDF file' into a search engine to see if anyone else was using that acronym already for a file extension. (of course, w3 even used it twice)

If you "know where to look something up" then you know it provided you've Bookmarked it.

Not necessarily. A web publisher might poorly maintain the URLs where documents can be found, or it might consider a document no longer worthy of publication. I've discovered that knowing the title and/or author of a document is sometimes more reliable than knowing a URL.

> Sitting in on the development of a standard and then
> patenting those components is dirty pool.

You may be interested in reading http://lists.xiph.org/pipermail/theora/2010-April/003769.html in this context...

But in general, what Apple is presumably doing here is making use of http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with

To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen

Too late.

The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.

What a novel idea!

But at least in my opinion we are on the right path.

We disagree, then, and that's fine. You make some good points in your post. Many plug-ins are subobtimal. Many technologies that are used through plug-ins aren't universally implementable, due to not being open standards. Distracting update mechanisms are annoying.

On the other hand, I regard all these things as accidental, or as results of choices you are free to make differently. Content could be offered through technology based on open standards. Implementations could be better. Updates could be managed quietly through a central update mechanism. In fact, these things are true for almost everything I use.

You may be right that putting a lot of functionality in the web browser will reduce the amount of plug-ins you have, and thus the amount of distractions and compatibility issues you get from updates. I don't have any of those issues now, so it probably wouldn't make a difference for me. What will happen is that browsers will become larger and more complex. I am afraid this will lead to more bugs, more vulnerabilities, and more frequent need to update. On balance, things may still get better for you, but they may get worse for me. That could explain why you think it's the right path, and I think it's the wrong path. :-)

Regarding images, this is rather a funny story. The img element was included in the first standardized version of HTML, HTML 2.0 in 1995. Images were already supported before that, but support varied by browser (as is the case nowadays, by the way): the original WorldWideWeb actually allowed for images, videos, and sound, though, as you say, not inline. Mosaic was the first web browser to display images inline, in 1993. Lynx, I think, still does not display images inline, being a text-based web browser. I believe that this is fully compliant with HTML, as HTML doesn't actually have much to say over how things are displayed (other than a few elements like b, and i).

Oh, and you should learn how to make links