The point of mentioning version 0 is because every major browser that is working on Shadow DOM is developing towards version 1. The v0 implementation was more experimental that made its way out there because Google doesn't always go through the proper standards practice. Version 1 is actually going through the normal standardization process. Firefox and Safari have the version 1 code in development, while Edge has it marked as a high priority consideration.
Vivaldi is not an open source fork of the old Opera code base. That code base was proprietary. It is blink based. The confusion is that it was founded by the former Opera co-founder/CEO, and aimed to restore features Opera lost when they moved to Blink. It's more a fork in the Opera consumer base and is not a fork of the code base.
I know it's easy to simply cut and paste from the original article (heck, it's one way to get people to actually read part of the article), but why not make corrections to gross errors?
Apple is not supporting WebRTC and has not implemented any of the features necessary for it. Not in desktop nor in mobile.
Or he could be the type that needs to worry about low powered mobile devices (like the type that Firefox OS initially targeted). Those devices would choke HARD trying to load jQuery.
Don't get me wrong, I definitely see the value in jQuery since it even fixes bugs in modern browsers. But lets not assume that just because someone is shying away from it that they are some newb that doesn't know better.
If I am writing a few line script for something then yes, I will spend the extra few minutes to first try to avoid using jQuery when I can. Adding a 100 kb (just guessing, I have not checked it lately) JavaScript library so that I can write what I want in 10 lines of jQuery rather than 60-100 lines of vanilla JavaScript just doesn't seem reasonable in my eyes.
Minor correction -- no version of IE (or Safari if we want to be technical) on Windows XP supports SNI. IE7 on Vista supports SNI, but not on XP. Also, Android 2.x is still pretty relevant given that it currently represents 9.6% of active Android users. The original Kindle Fire did not support SNI, though I believe with the second generation it did support SNI. Anyone with a pre-BB10 Blackberry also does not have SNI support.
Trust me, I would love to go SNI-based for SSL, but support wise we're just not there yet.
This is not supported by Firefox because it violates the CSS spec Basically, replaced elements (img, video, iframe, etc) cannot be modified via the content property because they eliminate any ability to replace them with accessible content. For example, an image cannot be replaced by its alt text.
I assume the parent was referring to IE's use of pointer events instead of the touch events. While many may accuse Microsoft of trying to split the web, this move was most likely done for two reasons.
The ability to simplify event handling with one type of event that is input method independent -- working for mouse, touch, and pen.
As a web developer I find the pointer event method to be technically superior to touch events. At present, patches to add pointer events to Blink-based browsers (the patch might have been added before the split from WebKit) and to Firefox exist, but I do not believe they have yet landed in other browsers. Sadly, with the lack of touch events it does bloat up code to support two different event models for touch browsers at this time.
Then I guess it's a good thing that IE8+ actually lets you specify which version of IE (from 7 on up) to display a website (though it is harder in IE11). Microsoft learned from the backlash they received for breaking intranets when they released IE7 so this really should not be an issue for anyone anymore.
You can install Firefox on Android. The Firefox OS Marketplace can be accessed from said Firefox. You can install apps on there and and it will load the app using Firefox. This is the same rendering engine -- the same HTML5 app -- using the same everything from Firefox OS.
When the standard has not been fully defined and is not working in any current browser, yes,
I'm all for pushing the bar of HTML5. I actually bought one of the Firefox OS developer phones. It's great for those of us who want to experiment, but I wouldn't make a big case if browsers working on experimental features have bugs in them. Heck, I wasn't aware that srcset had even gotten to an experimental implementation stage yet. No one else has implemented it. Kudos to Samsung for starting on it.
Actually, IE's ability to use their old rendering engine only goes back as far as IE7, not IE6. It's funny, given that quirks mode is really IE5.5 rendering you can test every version of IE from 5.5 up except for IE6.
Going back to the VM solution, Windows 7 Professional users are allowed to download something Microsoft calls Windows XP mode (using Virtual PC) and can create their own VMs of XP that do not require you to purchase another license. If you truly need to test in IE6, IE7, and IE8 all you need do is run all of the updates for XP for IE6 but do not install IE7, then copy that VM and run the update to IE7 and run the updates for that but do not install IE8, and then create another copy where you upgrade to IE8.
It's not really a hack. Opera Mini has always operated the way it does. It wasn't something they came up with just to get Opera onto iOS. That being said, this change may result in Opera Mobile being made available on iOS as well.
You're missing the major difference between what Opera did and what Amazon is doing. Opera did the rendering on their own server, while Amazon does it in the cloud. Totally different.
If the developer opportunities are good, i'm in. Problem is, calling something an App Store doesn't really change things much if you're just giving people access to a web site. Maybe they're going to focus on local apps written in html+css+js?
What you're looking for are called W3C Widgets. W3C Widgets currently run on Opera, and Vodafone, while T-Mobile and the Nokia S60 have have near standard W3C Widget implementations. It looks like Android is working on it, but Apple is doing everything in their power to fight this (all while touting how great HTML5 is).
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
What about Web sites that send cookies using the HTTPonly flag so that cookies aren't readable via JavaScript?
Have the Feds, or any other major service, looked at using DOM Storage as an alternative to cookies? DOM Storage allows for more data to be stored, and it removes extra data being transferred via every HTTP request. Yes, it is only available in modern browsers, but that need not stop its use, or at least making policy towards its use.
CSP is effectively server-side NoScript. And it isn't exactly new either. This has been in development as a Firefox extension for at least a year. The article mentions it being first crafted back in 2005.
The issue I take with this article is that they suggest this feature could even possibly be integrated into eBay or MySpace. These two giants seem like the exact opposite type of market that would use this -- any site that allows users to post their own data is not going to possibly survive the wrath they would catch if users had to explicitly allow the domains they want scripts to run on. For a corporate Web site yes, but for something for the masses or those of us that run a CMS? I don't see that as happening anytime soon.
I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.
Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.
I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.
Defer, though being a part of the HTML 4.01 spec, is only supported by IE. And even if other browsers supported it they could not use it because they need to know that the content had been loaded before they execute the tracking code.
The vast majority of developers just copy and paste the code as given. This code is an internal script tag that derives the protocol that is currently being used to then refer to the HTTP or HTTPS file using document.write, and then a second internal script tag that starts the tracking using your unique id while inside of a try/catch block.
Honestly, I believe Google is trying to piss people off with Google Analytics. First the code that they present that every developer just copies and pastes because Google tells them to loads the code in a blocking manner, and then a little while back they have turned off gzip compression so they file took even longer to transfer. Heck, I'd forgive them for the second if they would at least update the code they tell developers to copy and paste to load GA in a non-blocking manner. Yeah, it's a bit more code to tell developers to add to their pages, but the improved user experience makes it worth the extra few bytes. All you need to do is create a script element with the src attribute pointing to the URL for the via JavaScript, append the DOM node to the head, and then create a timer that checks to see if the GA code has finished transferring (which you'll know by testing to see if _gat is undefined) before you run initialize your tracking code, then kill the timer.
We're not in an era anymore where the specs or validators can keep up with the advancement in browser technologies. Should we not use ARIA attributes to mark up our content to provide better support for assistive technologies because the W3C validators do not pass them as valid, despite the ARIA specification saying that they should be?
We are in an era where both worlds can be meshed together. Put your content inside of the newly created video tag to first allow people to choose the player they want. Inside of that use the embed element for a Flash video, because that has a higher market share then any other way of doing things. That way you have covered your philosophical base covered first, then your practical base covered next. Everyone is happy.
Actually, if the post is to a HTTPS connection then you're fine. All that matters is that the address the form posts to is secured, not the original page that the form lay on.
Yours is a fairly common misconception. This is why a lot of web sites secure web traffic that doesn't need to be secured. While it doesn't do anything from a technical standpoint, it gives the user peace of mind. For my bank's web site, the home page automatically redirects you from HTTP to HTTPS. If you visit any of the other pages on a HTTP connection then the login box is removed and a link to login securely is there. It doesn't need to be that way, but it makes people feel more comfortable with their security.
myspace and flickr come up for 't' because of the 't's in 'http'. It really surprised me when I hit 'h' and saw every site I ever visited show up on my first experience using Firefox 3.
This is correct. It's been my experience that the only non-DOM related area that still has a great deal of cross browser incompatibilities is in the area of WYSIWYG editors. True, every browser supports the ability to turn on designMode, and Firefox 3 finally meant that every browser can enable contentEditable, but how the different browsers handle the editing process is completely incompatible with one another. Firefox seems to love to insert br tags in many situations. IE seems to actually handle hitting enter/return the most sensibly IMHO. That's the only thing I'll say that for in regards to WYSIWYG editors, because beyond that it is horrible. Generating font tags by default with no alternative but to ignore the browser specific functionality for most features, completely ignoring the W3C model for Ranges/Selections for their own proprietary TextRange/Selection objects, and other non-trivial headaches. IE's Text/Range/Selection issues give me the most trouble, as I often encounter DOM related bugs with them as well.
First off you are correct, you don't understand SSP. It does not force-enable JavaScript on the client's end. It allows site developers to force-disable JavaScript that they have not verified. It is sort of like NoScript for site developers that don't have 100% control over the source of their site. Consider the case where a site is built using a multi-author CMS. The group could agree to only use scripts that they wrote and ones server from [favorite_script_site]. SSP would prevent clueless Sally from adding a script from [pretty_flowers_dripping_down_the_screen].
SSP also disallows inline scripting, so this prevents people from injecting content inside a form whose results are automatically inserted on the page. Yes, the site author's script should scrub the results clean before displaying them to the user, but enabling SSP on the page would reduce the possibility of the script running if it made it through the scrubbing process.
This all being said, I do not understand the mass hysteria that I see from the/. crowd over Google Analytics. The purpose of GA is not the same as DoubleClick. DoubleClick's purpose is to serve you ads. GA's purpose is to provide site authors with information about their visitors so that they can properly tailor their pages to their customers better. One can find out which sections of one's site are popular and redesign their site to make it easier to get to, while pushing the lesser used sections off the home page. You can see how modified page content affects traffic over time. Think of your visiting habits as a vote for the way you'd like to see the site ran. Denying GA from running is effectively throwing your vote away.
Slashdot Mirror
The point of mentioning version 0 is because every major browser that is working on Shadow DOM is developing towards version 1. The v0 implementation was more experimental that made its way out there because Google doesn't always go through the proper standards practice. Version 1 is actually going through the normal standardization process. Firefox and Safari have the version 1 code in development, while Edge has it marked as a high priority consideration.
To be clear, Chrome deprecated v0 in April 2018 and will remove in 2019. If Google does nothing than Chrome will slow down on YouTube as it will have the same issues Firefox and Edge currently are feeling.
Vivaldi is not an open source fork of the old Opera code base. That code base was proprietary. It is blink based. The confusion is that it was founded by the former Opera co-founder/CEO, and aimed to restore features Opera lost when they moved to Blink. It's more a fork in the Opera consumer base and is not a fork of the code base.
I know it's easy to simply cut and paste from the original article (heck, it's one way to get people to actually read part of the article), but why not make corrections to gross errors?
Apple is not supporting WebRTC and has not implemented any of the features necessary for it. Not in desktop nor in mobile.
Or he could be the type that needs to worry about low powered mobile devices (like the type that Firefox OS initially targeted). Those devices would choke HARD trying to load jQuery.
Don't get me wrong, I definitely see the value in jQuery since it even fixes bugs in modern browsers. But lets not assume that just because someone is shying away from it that they are some newb that doesn't know better.
If I am writing a few line script for something then yes, I will spend the extra few minutes to first try to avoid using jQuery when I can. Adding a 100 kb (just guessing, I have not checked it lately) JavaScript library so that I can write what I want in 10 lines of jQuery rather than 60-100 lines of vanilla JavaScript just doesn't seem reasonable in my eyes.
Minor correction -- no version of IE (or Safari if we want to be technical) on Windows XP supports SNI. IE7 on Vista supports SNI, but not on XP. Also, Android 2.x is still pretty relevant given that it currently represents 9.6% of active Android users. The original Kindle Fire did not support SNI, though I believe with the second generation it did support SNI. Anyone with a pre-BB10 Blackberry also does not have SNI support.
Trust me, I would love to go SNI-based for SSL, but support wise we're just not there yet.
This is not supported by Firefox because it violates the CSS spec Basically, replaced elements (img, video, iframe, etc) cannot be modified via the content property because they eliminate any ability to replace them with accessible content. For example, an image cannot be replaced by its alt text.
I assume the parent was referring to IE's use of pointer events instead of the touch events. While many may accuse Microsoft of trying to split the web, this move was most likely done for two reasons.
As a web developer I find the pointer event method to be technically superior to touch events. At present, patches to add pointer events to Blink-based browsers (the patch might have been added before the split from WebKit) and to Firefox exist, but I do not believe they have yet landed in other browsers. Sadly, with the lack of touch events it does bloat up code to support two different event models for touch browsers at this time.
Then I guess it's a good thing that IE8+ actually lets you specify which version of IE (from 7 on up) to display a website (though it is harder in IE11). Microsoft learned from the backlash they received for breaking intranets when they released IE7 so this really should not be an issue for anyone anymore.
You can install Firefox on Android. The Firefox OS Marketplace can be accessed from said Firefox. You can install apps on there and and it will load the app using Firefox. This is the same rendering engine -- the same HTML5 app -- using the same everything from Firefox OS.
When the standard has not been fully defined and is not working in any current browser, yes, I'm all for pushing the bar of HTML5. I actually bought one of the Firefox OS developer phones. It's great for those of us who want to experiment, but I wouldn't make a big case if browsers working on experimental features have bugs in them. Heck, I wasn't aware that srcset had even gotten to an experimental implementation stage yet. No one else has implemented it. Kudos to Samsung for starting on it.
Actually, IE's ability to use their old rendering engine only goes back as far as IE7, not IE6. It's funny, given that quirks mode is really IE5.5 rendering you can test every version of IE from 5.5 up except for IE6.
Going back to the VM solution, Windows 7 Professional users are allowed to download something Microsoft calls Windows XP mode (using Virtual PC) and can create their own VMs of XP that do not require you to purchase another license. If you truly need to test in IE6, IE7, and IE8 all you need do is run all of the updates for XP for IE6 but do not install IE7, then copy that VM and run the update to IE7 and run the updates for that but do not install IE8, and then create another copy where you upgrade to IE8.
Windows XP mode is not available on Windows 8. Yet another reason why businesses may hold out on upgrading ....
It's not really a hack. Opera Mini has always operated the way it does. It wasn't something they came up with just to get Opera onto iOS. That being said, this change may result in Opera Mobile being made available on iOS as well.
You're missing the major difference between what Opera did and what Amazon is doing. Opera did the rendering on their own server, while Amazon does it in the cloud. Totally different.
If the developer opportunities are good, i'm in. Problem is, calling something an App Store doesn't really change things much if you're just giving people access to a web site. Maybe they're going to focus on local apps written in html+css+js?
What you're looking for are called W3C Widgets. W3C Widgets currently run on Opera, and Vodafone, while T-Mobile and the Nokia S60 have have near standard W3C Widget implementations. It looks like Android is working on it, but Apple is doing everything in their power to fight this (all while touting how great HTML5 is).
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
What about Web sites that send cookies using the HTTPonly flag so that cookies aren't readable via JavaScript?
Have the Feds, or any other major service, looked at using DOM Storage as an alternative to cookies? DOM Storage allows for more data to be stored, and it removes extra data being transferred via every HTTP request. Yes, it is only available in modern browsers, but that need not stop its use, or at least making policy towards its use.
CSP is effectively server-side NoScript. And it isn't exactly new either. This has been in development as a Firefox extension for at least a year. The article mentions it being first crafted back in 2005.
The issue I take with this article is that they suggest this feature could even possibly be integrated into eBay or MySpace. These two giants seem like the exact opposite type of market that would use this -- any site that allows users to post their own data is not going to possibly survive the wrath they would catch if users had to explicitly allow the domains they want scripts to run on. For a corporate Web site yes, but for something for the masses or those of us that run a CMS? I don't see that as happening anytime soon.
I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.
Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.
I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.
Honestly, I believe Google is trying to piss people off with Google Analytics. First the code that they present that every developer just copies and pastes because Google tells them to loads the code in a blocking manner, and then a little while back they have turned off gzip compression so they file took even longer to transfer. Heck, I'd forgive them for the second if they would at least update the code they tell developers to copy and paste to load GA in a non-blocking manner. Yeah, it's a bit more code to tell developers to add to their pages, but the improved user experience makes it worth the extra few bytes. All you need to do is create a script element with the src attribute pointing to the URL for the via JavaScript, append the DOM node to the head, and then create a timer that checks to see if the GA code has finished transferring (which you'll know by testing to see if _gat is undefined) before you run initialize your tracking code, then kill the timer.
The embed tag is one of the official new elements in HTML5.
We're not in an era anymore where the specs or validators can keep up with the advancement in browser technologies. Should we not use ARIA attributes to mark up our content to provide better support for assistive technologies because the W3C validators do not pass them as valid, despite the ARIA specification saying that they should be?
We are in an era where both worlds can be meshed together. Put your content inside of the newly created video tag to first allow people to choose the player they want. Inside of that use the embed element for a Flash video, because that has a higher market share then any other way of doing things. That way you have covered your philosophical base covered first, then your practical base covered next. Everyone is happy.
Actually, if the post is to a HTTPS connection then you're fine. All that matters is that the address the form posts to is secured, not the original page that the form lay on.
Yours is a fairly common misconception. This is why a lot of web sites secure web traffic that doesn't need to be secured. While it doesn't do anything from a technical standpoint, it gives the user peace of mind. For my bank's web site, the home page automatically redirects you from HTTP to HTTPS. If you visit any of the other pages on a HTTP connection then the login box is removed and a link to login securely is there. It doesn't need to be that way, but it makes people feel more comfortable with their security.
myspace and flickr come up for 't' because of the 't's in 'http'. It really surprised me when I hit 'h' and saw every site I ever visited show up on my first experience using Firefox 3.
The awesome bar really needs to ignore protocols!
This is correct. It's been my experience that the only non-DOM related area that still has a great deal of cross browser incompatibilities is in the area of WYSIWYG editors. True, every browser supports the ability to turn on designMode, and Firefox 3 finally meant that every browser can enable contentEditable, but how the different browsers handle the editing process is completely incompatible with one another. Firefox seems to love to insert br tags in many situations. IE seems to actually handle hitting enter/return the most sensibly IMHO. That's the only thing I'll say that for in regards to WYSIWYG editors, because beyond that it is horrible. Generating font tags by default with no alternative but to ignore the browser specific functionality for most features, completely ignoring the W3C model for Ranges/Selections for their own proprietary TextRange/Selection objects, and other non-trivial headaches. IE's Text/Range/Selection issues give me the most trouble, as I often encounter DOM related bugs with them as well.
First off you are correct, you don't understand SSP. It does not force-enable JavaScript on the client's end. It allows site developers to force-disable JavaScript that they have not verified. It is sort of like NoScript for site developers that don't have 100% control over the source of their site. Consider the case where a site is built using a multi-author CMS. The group could agree to only use scripts that they wrote and ones server from [favorite_script_site]. SSP would prevent clueless Sally from adding a script from [pretty_flowers_dripping_down_the_screen].
SSP also disallows inline scripting, so this prevents people from injecting content inside a form whose results are automatically inserted on the page. Yes, the site author's script should scrub the results clean before displaying them to the user, but enabling SSP on the page would reduce the possibility of the script running if it made it through the scrubbing process.
This all being said, I do not understand the mass hysteria that I see from the /. crowd over Google Analytics. The purpose of GA is not the same as DoubleClick. DoubleClick's purpose is to serve you ads. GA's purpose is to provide site authors with information about their visitors so that they can properly tailor their pages to their customers better. One can find out which sections of one's site are popular and redesign their site to make it easier to get to, while pushing the lesser used sections off the home page. You can see how modified page content affects traffic over time. Think of your visiting habits as a vote for the way you'd like to see the site ran. Denying GA from running is effectively throwing your vote away.