Slashdot Mirror

I can't find a language spec for "web technologies"

In the context of browser extensions, the relevant specs are ECMA-262, CSS, HTML Living Standard, and WebExtensions API.

Are your family and friends even going to CARE to try to connect to your network if the internet is down.

Yes, because with the Internet down, at least you have some entertainment stored on your NAS that visitors can view together. This could, for example, include a mirror of Wikipedia's best articles (those in GA, A, and FA classes).

There were plans at some time to make even the Fullscreen API secure-only

Of course you could just have plaintext HTTP enabled on your NAS for media access.

That's possible but impractical once browsers make HTTPS mandatory for using the Fullscreen API in documents served from anywhere but localhost. (The LAN is not localhost.) From the Secure Contexts spec, section 4.3 "Risks associated with non-secure contexts":

The ability to manipulate a user agent’s native UI in some way which removes, obscures, or manipulates details relevant to a user’s understanding of their context. [FULLSCREEN] is a good example.

A proof of concept for phishing using the Fullscreen API exists.

You mean like Whatwg? I used to ignore it as it was kind of webkit and Google oriented back in the day but that was awhile back.

July 2, 2009 was the day that Tim Berners-Lee abandoned a free and open web.

https://www.cnet.com/news/an-epitaph-for-the-web-standard-xhtml-2

That was the day that he announced the termination of his XHTML2 standard, and allowed Apple, Google, and others to dictate the HTML5 "standard". (And I place "standard" in scare quotes because it isn't really a standard. In fact, they acknowledge this fact, and prefer to use the deliberately deceptive term living standard .)

The fight against DRM in the HTML standard is already lost. Tim Berners-Lee gave up 8 years ago, it's just that most people didn't notice until now.

Here's a list of the "-webkit"-prefixed properties.

https://compat.spec.whatwg.org...

At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced, since most of the listed properties are aliases for the standard versions of those properties. I.e. WebKit was the first rendering engine to support those properties, but it did so while the web standard was being finalized, so it prefixed those properties, as it is supposed to. Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.

Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.

If you insists[sic] on using a plugin that makes your browser non standards compliant...

I'm sorry but the standards you speak of don't require anyone to load all content. That's the choice of
the user and his/her browser. There a standard for HTML https://html.spec.whatwg.org/.
There is no standard on "how to browse a web page".

Specifically, it's not required to load the main page ("index.html/php"). (You can deep-link instead).
It's not required to load everything linked to by that main page. It's not required to load anything at all.

It is assumed when one visits a site with a web browser one will load up the index page and all subsequent
referenced links, but that's not in ANY standard; a browser that doesn't do that is NOT out of compliance
with standards, and further more if we go by de facto standards then the standards IS not loading ads.

Have a happy browsing day. Don't confuse "standards compliant" with "being required to load an
entire page and all its referenced links."

E

JavaScript was originally just going to control some minor browser behavior; moving windows around, etc. So it didn't need to be efficient or well thought out. Then it got extended and overused so much that it slowed down computers so noticeably that it caught the attention of everyone.

Actually, web technologies were horrible, with every major browser adding its own incompatible extensions and the W3C barricaded in an ivory tower, and Microsoft extended their version of Javascript to support the insane uses of Internet Explorer as the Windows Update control panel and stuff like that. Then Microsoft won the browser wars, and web technology stagnated, until some people figured out that "the XML HTTP thing" could be used to create web applications that communicated in objects instead of reloading all the time, and Jesse Garrett gave it the name Ajax. Then there was a business use for Javascript to be fast.

Then Douglas Crockford discovered that Javascript has good parts, the WhatWG started doing HTML5, and now many web sites don't show anything at all without Javascript, but at least you can compile a sane language into Javascript.

Most of the HTML5 specifications gets developed here first:

http://www.whatwg.org/specs/we...

Then eventually after a long process will end up here:

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

However Picture-tag actually came from the community first, not the W3C or the vendors directly:
http://responsiveimages.org/ only later did it become http://www.w3.org/community/re... and later became part of the HTML5-specification.

Ehmm. W3C is the community, WhatWG is the vendors. The whole point of WhatWG was to coordinated between browser vendors.

Most of the HTML5 specifications gets developed here first:

http://www.whatwg.org/specs/we...

Then eventually after a long process will end up here:

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

However Picture-tag actually came from the community first, not the W3C or the vendors directly:
http://responsiveimages.org/ only later did it become http://www.w3.org/community/re... and later became part of the HTML5-specification.

which standard? html5 isn't a standard at all, let alone well known. it's a wannabee.

Oh? You'd better tell these guys to stop work then.

quick! point to the document showing that a select tag has a value attribute!

It's in HTML.

This very much is one of the major achievements of HTML5: specifying what is interoperable and required to avoid breaking the web, but historically undefined. One couldn't practically launch a web browser without reverse-engineering others.

But once W3C makes it part of HTML5, then anything w/o DRM support is not standards compliant.

Well, actually, I'm not sure the W3C has ever been relevant to developing new standards that get implemented.

With such a low UID, I'm guessing you were around for the whole HTML4/XHTML debacle. And SVG. And MathML. Part of the problem was that for much of the W3C's history, IE6 was the dominant browser, but the XML madness was madness.

The only way we got to HTML5 is by having a bunch of companies go off and make their own WhatWG, and as soon as HTML5 got into the W3C they announced they were working on the next HTML standards. Outside the W3C.

HTML5 never will be "finalized," since it's not a W3C recommendation.

Its a W3C Candidate Recommendation that is scheduled to reach Recommendation status next year.

The whole idea is that it will be a living, evolving standard, with various features being adopted piecemeal in browsers.

You are likely confusing the WHATWG HTML Living Standard (which has no number) with W3C HTML5. They are two different things.

In other words, it will always be in development and there will never be an "HTML6."

There may or may not be an HTML 6, but there is already an HTML 5.1 in development.

> Imagine that the first version of HTML been designed with a binary encoding with single-byte tags, and a new version introduced multibyte tags. Older programs would not understand the multibyte tags and would not be able to display a document containing them, not even in a graceful degradation mode.

There is no reason why we just couldn't of used multi-byte tags from the beginning IF they were really needed.

i.e.
Bytes Meaning
0x00..0x1F single byte for all the _common_ tags: a, b, i, etc... (Huffman encoding)
0x20..0x7F standard ASCII
0x80 multi byte tag + Unicode(schema to be worked out)

Let's step back for a moment and look at the problem we are trying to solve:

How many tags do browsers _really_ need ? If we are using more then 256 tags then system is probably over-engineered.

HTML5 currently has ~ 114 tags with around ~25 obsolete so 256 tags looks like it it would be more then enough.
http://www.whatwg.org/specs/web-apps/current-work/multipage/

Buts pretend we actually have a valid use for 256 tags. There is no reason that we couldn't just use 16-bits. Now if we really are going to need more then 65536 tags then we obviously are doing something _wrong_.

The better solution would of been to just use a 32-bit hash of the tag. That way the tag would simply be a hash value of the ASCII tag name. Much faster for browsers to parse, store, and render. When I wrote my mni HTML render last year internally that is what I did -- first thing was to get rid of all this stupid variable insensitive name tag crap and replace it with a constant unique id by generating a hash from the case insensitive tag. This way you will effectively "never" run out of tags.

Another optimization is that we can treat all the attributes as an array/vector of pairs, where the key is the same standard 32-bit hash value. :-)

HTML is a cluster fuck because it is over-engineered.

damn side nicer than this horrible thing or this fecal matter.

The only scripting functionality in HTML5 is the same as HTML has had since Netscape introduced JavaScript in '95. There's nothing new there. You can see for yourself: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html

It's true that HTML5 includes a scripting functionality, but it's like saying that the new Volvo has a steering wheel.

Whoever, is forking the process should trademark a new name and call their standard by that name. To keep calling it "HTML5" is just mean.

The WHATWG standard is the HTML Living Standard.

The W3C standards effort is HTML5.

See the blog post (from January 2011, so this is decidedly not news) announcing the whole process shift at WHATWG.

...that this split officially happened in January 2011. It's also a shame that HTML5 has been a "living standard" for two years, seven months and eleven days. At least you try, /., at least you try.

Ian Hickson is the editor of both docs (he's actually the editor of the main HTML standard, the WHATWG one; the draft hosted by the W3C is really nothing more that an old and incomplete copy that nobody among browser vendors takes seriously).

He explained very clearly the past and current situation: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html

And, yes, the WHATWG has done an excellent job so far, bringing much needed features to the web and creating an era of faster and more interoperable browsers. If they had just waited for the W3C we would still be stuck with HTML 4.01, IE6, Flash and other plugins.

Also this is not a new development, HTML (from WHATWG) has started gradually leaving the HTML5 (from W3C) behind a long time ago. Where the two differ, all major browsers (including IE) either already follow HTML or plan to. See this post from more than a year ago: http://blog.whatwg.org/html-is-the-new-html5

When people talk about HTML5 features in browsers and websites, they actually refer to the HTML standard. The HTML5 "working draft" on the W3C website doesn't even support the old 2D canvas API, which is implemented by all browsers!

Until now the two standards bodies working on HTML5 (WHATWG and W3C ) have cooperated. An announcement by WHATWG makes it clear that this is no longer true. WHATWG is going to work on a living standard for HTML which will continue to evolve as more technologies are added. WC3 is going the traditional and much more time consuming route of creating a traditional standard which WHATWG refers to as a 'snapshot' of their living standard.

This (except correctly referring to the W3C instead of "WC3", whatever that might be) was announced on the WHATWG blog on January 19, 2011. How is this news?

Whatever happens, the future has just become more complicated — now you have to ask yourself 'Which HTML5?'"

Actually, no -- prior to the change at WHATWG in 2011, there were two HTML5 efforts (WHATWG and W3C). Now there is only one (W3C). WHATWG's living standard is for HTML, with no number attached to it. The two standards have somewhat different purposes. The WHATWG living standard represent the common functionality that browser vendors have agreed to implement, the W3C standard is more conservative. In theory, given the goals of the two standards, the W3C one would be the better one for app developers to target and the WHATWG one would be mostly a tool for browser vendors to align on what features they were going to work toward getting to the point where they were generally usable, and be much more forward looking. But that requires the W3C to draw a line in the sand and commit to finishing HTML5 (and then get started on HTML6, etc.) Otherwise, you end up with the WHATWG work that is officially a living standard, and the W3C work is a series of "Working Drafts" chasing the WHATWG living standard but never actually producing a stable standard, either.

This was mentioned over a year ago that this was happening? (January 2011 ! )

http://blog.whatwg.org/html-is-the-new-html5

Nice argument, well cited, and highly intelligent. I can't disagree. Oh wait, you didn't actually have an argument.

Neither did you. You just namedropped XHTML2 and that was it.

Good software development is all about modularity, ensuring a spec is can grow to the dynamic needs of something like the web demands that you define the generic building blocks, and let people build whatever they need from there. XHTML2 was trying to do both of these things.

It was trying to do it in a bad way through XML namespaces, leading to namespace confusion.

No, it's about defining document structure.

That, too. They go hand in hand.

HTML still defines structure regardless of any semantic meaning.

The only structure it would define is that of a tree devoid of meaning.

Wrong because it's right? what???

If all older web browsers were IE browsers, you'd be right. But there are lots more of them out there that will render HTML5 just fine.

As opposed to a mishmash of ill defined tags with arbitrary meanings?

They're not ill defined tags with arbitrary meanings.

If there's disagreement about something fundamental within the spec then the spec has failed to define something properly

Disagreement about the semantic meaning of a bunch of elements is hardly fundamental. Besides, the spec isn't even done. If no one disagreed on things we wouldn't need anyone to work on specs.

Yes, well that's one advantage of a living spec I suppose.

We're talking about HTML5, not the versionless living spec living at the WHATWG. Did you forget that the W3C embraced the WHATWG's work and used that as a basis for HTML5?

Come back when you're living in reality again.

The relevant spec ( http://www.whatwg.org/specs/web-apps/current-work/#refsEDITING ) was last edited yesterday (28th March 2012). Damn hard to hit a moving target and all that.

Which makes me prefer a standalone app instead of a website for utilities.

Ideally a web application SHOULD work offline using the Application Cache and Web Storage components of the HTML5 stack. But some publishers are under the impression that offline access is a premium feature.

Multi-threading in JS is handled by web workers.

Oh, great! So now we're outsourcing even more textile jobs to anyone willing to work online, is that it? Sheesh!

(On a more serious note, thank you for that informative link.)

I am going to assume you are aware of how those functions work (specifically that they cannot interrupt the current thread if it is busy; they are only handled if the thread is idle) and that they themselves are not multi-threaded or have anything to do with multi-threading. It's not 100% clear from your post, though.

Multi-threading in JS is handled by web workers.

It is called navigation buttons and navigation relation attributes. (link relation attributes or whatever way you want to put it)
These allow you to connect content on your server intelligently, then a browser user would only need to hit the next / previous / parent page button on their toolbar. (I'm sure there was a few other ones I have forgotten, first and last probably)
But Opera seem to have been the only ones who really supported this by default. I think Firefox has support for it, but you need to add it on. Chrome has no such support at all. And I don't even know what IE supports these days, ignored it entirely since I don't need to care about them.

Why are they trying to reinvent the thing that they were known for? (Accessibility)

Not only that, it appears to be a bitch to even find any documentation on these things as it is!
Here is some of the extensions to navigational relations added to HTML5
Road to HTML5 link relations

Any day now I'm expecting they'll go versionless like HTML 5 did ( http://blog.whatwg.org/html-is-the-new-html5 ).

Ericsson had done so in 2010:

https://labs.ericsson.com/developer-community/blog/beyond-html5-implementing-device-and-stream-management-webkit

The "Device API" however has been replaced with "Video conferencing and peer-to-peer communication":

http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#introduction-10

  I'm not aware of anyone that supports it currently.

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.

You need to check the spec. Canvas permits compositing images. In a typical implementation, these will be stored as textures on the GPU and composited in hardware (unlike Flash, which does it on the CPU, to keep your laptop nice and warm). You're right about the lack of a scene graph API - canvas is lower level than that. If you want a scene graph, use SVG (or implement a scene graph on top of canvas).

The stream API, formerly called the <device> element, has zero browser support. Adobe Flash Player, on the other hand, runs on almost every desktop PC. It also runs on any Android device with an OS version that was current around the time they started putting front-facing cameras on phones.

Not really. You may notice no one's actually advocating the creation of more Flash content, and that's because we have HTML5 here, which even after Apple crippled it with its tantrums to the W3C it remains a much superior choice for interactive web content.

What tantrums are you referring to ? I know apple was part of the workgroup that originally created and pushed for HTML5, the WHATWG:

"The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born."

So it seems likely they take an active role in guiding the process.

The thing with Flash however is just that, well, support for even outdated and inefficient formats like Flash is one of the advantages of an open ecosystem such as Android's over Steve Jobs' walled prison, and is an example popular and simple enough that it won't go over the layman's head (as would, for instance, the ability to develop in any language you choose).

Not just inefficient, broken. TFA states that he could hardly get a balloon-pop game, right out of a Flash beginners guide, to work right. I'll grant you that if they get it to work right and they can make it efficient enough to sip battery power instead of guzzling it, it would be a boon. If that were the case, however, would Apple keep it out ? The conspiracy theory says yes, I don't buy it though.

Well, that and the fact that what Apple's proposing in its stead (HTML5/h.264) is in many ways worse from a freedom standpoint than Flash itself so really, freedom advocates are kind of stuck between a rock and a hard place in this Adobe vs Apple fight.

I don't buy that argument either but lets not go into the whole h.264 thing except to say that that race has been run and h.264 came out on top much like mp3 did. The difference with Flash is that where Flash is wholly closed at least in the combo with HTML5 you've got the choice of easily swapping out h.264 with WebM if you support it on the client.

That's why it's a requirement to specify the language used.

Only for a language other than the standard default.

Up-front disclosure: I've been involved with HTML5 since 2006, and worked for Opera Software since 2009, and (among other things) am QA for HTML/DOM/etc. implementation.

2022 is far from insane: CSS 2.1 has been under development since 1998, and is yet to reach REC (though hopefully will this year) â" and CSS 2.1 is just a minor update to CSS 2.

Yes, for most practical purposes the spec will be done long before it reaches REC, but writing a testsuite that is considered complete enough is massively-time consuming, and having two implementations passing every test will take time (again, we're still not there with CSS 2.1 after 13 years).

HTML5 will almost certainly take longer than CSS 2.1 because not only does it just clarify prior ambiguities, but it also adds a fairly large number of new features. Also, the ambiguities that are being clarified are often large gaping holes (e.g., there is no definition of how cross-origin access between frames should work, what should be allowed, prior to HTML5) in previous specifications, and as such each browser has its own design for quite what happens in those areas (normally similar except in the edge-cases from reverse-engineering), and quite a lot of those designs will be non-trivial to change to match HTML5 for all browser vendors in places, meaning there will be quite a lot of things that will remain different in the edge-cases for a while.

Note that under what the W3C Process requires today for a spec to proceed to REC neither HTML 4 nor CSS 2 would yet be a recommendation (indeed, such documents are closer to the quality that would be expected of an early working draft nowadays).

For a probably more refined answer than this, see http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F.

There is already a kitchensink in the specification. Although at this point it is only an image: http://images.whatwg.org/abstract.png http://www.whatwg.org/specs/web-apps/current-work/complete/ Anyway support for the device-tag is planned for the next big update. The device-tag allows access to the webcam (like Flash currently does), serial ports (so you can use your barcode reader with your webapplication), but also supposedly USB-stick-fileaccess (maybe useful for something like ChromeOS ?) and so on. Yes, yes, all with a banner at the top of the browser "would you like to give this website access to the filesystem of your recently plugged in USB-stick.", bla, bla.

There is already a kitchensink in the specification. Although at this point it is only an image: http://images.whatwg.org/abstract.png http://www.whatwg.org/specs/web-apps/current-work/complete/ Anyway support for the device-tag is planned for the next big update. The device-tag allows access to the webcam (like Flash currently does), serial ports (so you can use your barcode reader with your webapplication), but also supposedly USB-stick-fileaccess (maybe useful for something like ChromeOS ?) and so on. Yes, yes, all with a banner at the top of the browser "would you like to give this website access to the filesystem of your recently plugged in USB-stick.", bla, bla.

Remember HTML5 is the new HTML...Some say it the other way around :) http://blog.whatwg.org/html-is-the-new-html5
Anyways It's called HTML from now on.

3 years is an eternity in web time. By 2014, the web will have evolved once again into something nobody can foresee today.

In three years, the W3C HMTL5 standard will probably document a safe, nearly universally available, baseline standard. It won't document anything interesting or cutting edge, but that's not really the point, that's what the "living standard" for HTML maintained by WHATWG, which "actually now defines the next generation of HTML after HTML5."

Who cares what the W3C says? WHATWG are the people who are actually getting stuff done -- and they're getting it done with real world implementations too.

They do if they depend on more than 5 MB of data. The page you linked mentions storage quotas, and there exist popular user agents that don't let the user increase the quota past 5 MB.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web

Web apps don't necessarily depend on a 24/7 connection to the web.

I don't think the W3C has given up on the HTML5 name. This article is referencing the WHATWG (which unofficialy stands for "What Working Group?" http://www.whatwg.org/) which is made up of individuals from those four companies. They think the W3C moves too slowly and are trying to push forward on their own.

HTML has not been abandoned by the W3C and every web company agrees (even Apple, Google, Opera and Mozilla) that the W3C is the official source of standards.

quoting the original announcement

As there is still interest in publishing a snapshot of HTML5, the W3C is still working on that (in conjunction with the WHATWG).

Since when did Google become the keepers of the HTML spec?

Google is not "the keepers of the HTML spec". Ian Hickson, who happens to work for Google, is the editor of the HTML5 spec. Usually, spec maintainers work for a firm involved in the area the spec addresses.

I think a randomly changing feature-set sounds like a bad idea.

In none of the discussion of this change has there been any indication that the WHATWG process for HTML will involve random changes.

HTML is supposed to be a standard, not something which just changes without any real control behind that.

There is a process, which is discussed in the WHATWG FAQ. The process just doesn't involve version numbers anymore.

Go straight to the source instead.

No. Forcing the WebM/Theora video issue should also have the side effect of bringing support for vorbis.

The goal is not to drop patented algorithms, it is to force everyone to support unpatented alternatives. I think dropping H.264 should be enough to accomplish this goal. If not, then yes, I do support dropping MP3.

Also note, MP3 decoder patents likely expire in 2012, and encoder patents expire in 2017, vs 2028 for H.264. That's a whole different kettle of fish on those timescales.

But wait, I can play dumb flash games over the web for free.

Not on your MacBook on the bus/train/carpool unless you pay $60/mo for mobile broadband. Locally installed applications are more often designed to work offline. Does Adobe Flash Player even support anything like HTML5's CACHE MANIFEST?

... Besides MPEG4 will soon be public domain anyway (2015 if I recall correctly) which is just as good as open source.

According to this page, the last patents for h264 may not expire until 2028:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020737.html

It's not their audio or video tag and they also didn't invent it.

http://www.whatwg.org/specs/web-apps/current-work/#devices