JavaScript and CSS changes in IE Mobile for Windows Phone 7

For IE Mobile in Windows Phone 7, we've made a couple of JavaScript and CSS enhancements that you can try out today in the Windows Phone 7 Emulator.

The new scripting functions are:

• getElementsByClassName(name): given the class specified by name, returns all of the elements or sub-elements within the scope of this function call
• querySelector(selector): given the selector, returns the first element within the sub-tree of the scope of this function call that matches the selector
• querySelectorAll(selector): given the selector, returns all elements within the sub-tree of the scope of this function call that match the selector

We've also added support for the -webkit-text-size-adjust CSS selector. This selector allows you to control how text on the Web page is scaled to increase readability for the user (you can also use  -ms-text-size-adjust, IE Mobile recognizes both).

You can set the value of the selector to "none", "auto", or a percentage value.

• "none": turns off text size adjustment. For example, html { -ms-text-size-adjust:none } turns off text adjustment for the entire page.
• "auto": sets the text size adjustment to the automatic setting
• percentage: use the specified percentage value to adjust text size. For example, .title { -ms-text-size-adjust: 150% } will adjust the text size for elements that are assigned the "title" CSS class.

[Update 05/11/2010: based on community feedback, we will only be implementing the -ms- prefix, not the -webkit- one.]

Joe Marini
Principal Program Manager
Windows Phone

Comments

• Anonymous
  May 10, 2010
  Is this team the same team that makes IE mobile for Windows Phone 6.X?  What about Zune HD's browser? Will you continue to advance 6.X's browser at all?

• Anonymous
  May 10, 2010
  The comment has been removed

• Anonymous
  May 10, 2010
  Dan - we added support for both the -webkit- and -ms- prefixes for text-size-adjust because they both do exactly the same thing, and we want to make sure that Web pages are viewed the way that developers intended them to be. Vendor prefixes are not intended to specify a specific browser - they are only there as a way to namespace items that have not yet become a standard.

• Anonymous
  May 10, 2010
  Hi Tom, The team that created the browser for the 6.x series has morphed into the team that is now working on IE for Windows Phone. It is separate from the team that works on the Zune browser. We are now focused on WP7; there are no plans to further enhance 6.x browsers.

• Anonymous
  May 10, 2010
  I know what prefixes are for, and you're implementing them wrong. What you're assuming here is that you've made your implementation match the webkit implementation exactly. I would like to trust you, I'm just having a hard time when I think about all of the hours I've put into working around IE bugs in my life. Vendor prefixes allow browsers to stay out of my way until the spec is finalized and implemented correctly. By deciding to implement a different browser's prefix you are explicitly getting in my way. You're also assuming that if a developer implements something in webkit, they mean to implement it the same in ie mobile. You're assuming that you know what web developers want better than they do. You're wrong in saying that "vendor prefixes are not intended to specify a specific browser". They are, until the spec is final, and the implementation is as good as it's going to get. At that point, the prefix is removed.

• Anonymous
  May 10, 2010
  Dan - let me clarify what I meant by "targeting specific browsers". If you're planning on delivering different style sheets to different browsers, there are ways of doing that such as server-side UA filtering. However, for what you are talking about, the following would easily mitigate your concern: body {  -webkit-text-size-adjust: 120%;  -ms-text-size-adjust: 140%; } IE Mobile would simply pick up the second definition and override the first.

• Anonymous
  May 10, 2010
  Be that as it may, what happens here: body { -ms-text-size-adjust: 140%; -webkit-text-size-adjust: 120%; } Can we assume that the MS prefix still takes precedence on IE mobile? Is this even something that I should have to worry about? By supporting the vendor prefixes of other browsers, you are opening up a giant can of worms. You're doing this so that sites look good in your browser since almost nobody is using the -ms- prefix yet. We will, though, when it's worth our time to do so. Just concentrate on making an awesome browser. Leave the CSS implementations to us.

• Anonymous
  May 10, 2010
  Dan - I will certainly take this feedback to the team. Stay tuned.

• Anonymous
  May 10, 2010
  Why exactly do you suppose it's called a vendor prefix and specifically notes a product name which is not owned by Microsoft, in this case "webkit"? Using a vendor prefix means you're specifically targeting a certain rendering engine, often because their implementation may still be subject to change or could, in less frequent cases, be removed. A good example of this are single rounded borders, which is "border-left-top-radius" according to the spec, thus "-webkit-border-left-top-radius" for WebKit-based browsers. Mozilla Firefox has a different syntax for these, namely "-moz-border-radius-topleft". These prefixes are reserved for other vendor-specific implementation as well, such as "-webkit-autofill" for automatically filled in form fields. Microsoft is making great progress with Internet Explorer and certainly is catching up with the other browsers, but this is just absurd and should certainly be considered harmful. A vendor prefix is exclusive to a vendor, and should remain exclusive as well.

• Anonymous
  May 10, 2010
  Thank you, and thanks for taking the time to have the discussion iemoblog!

• Anonymous
  May 10, 2010
  +1 on Dan's comments; this is one of the most disingenuous and ill-thought out strategies to come out of Microsoft's web platforms in a while, and given the general negative vibe felt amongst web developers towards Internet Explorer in general, that's saying something. Come clean here: you didn't do this because you ‘want to make sure that Web pages are viewed the way that developers intended them to be’. If that was your intention, you'd have left well alone. No; your intention was to ride on the backs of sites which have been optimised for MobileSafari. That you feel sufficient number of sites are using this pattern already is worrying enough, but that's something you should be bringing up in your attempts to push for standardisation within the W3C's CSS3 working group. Vendor prefixes are — more or less — the CSS equivalent of private APIs. Use them at your peril, because they could change at a moment's notice. This warning applies equally to both authors of web content and  developers of web browsers. The difference is that content authors can usually change their use of these rules pretty easily; you on the other hand risk setting this in stone and giving web developers a whole new generation of problems to work around.

• Anonymous
  May 10, 2010
  I would like to echo Dan's concerns. As I understand it, and as you say, the vendor prefixes are there to "to namespace items that have not yet become a standard". One implication of them not being a standard is that they are subject to potential change. It's in the realm of possibility that Webkit decide they want to change the implementation on the one of their vendor-prefixed rules. In which if it has been adopted - like this case - by another browser would leave us web developers as if no one had used a vendor prefix to start with. Adopting another vendor's prefix, while no doubt attractive in the short term, seems to do little but pollute the namespace. As someone working on implementing websites this seems to set a worrying precedent.

• Anonymous
  May 11, 2010
  Hi all, After hearing everyone's feedback, we've re-thought the decision. We've posted a follow-up blog entry for anyone who's interested. Thanks to all who weighed in.

• Anonymous
  May 11, 2010
  Let me state it very clearly: vendor prefixes are here for experimental purposes by the vendor represented in the prefix. I strongly recommend removing immediately that -webkit-* property from Mobile IE. Daniel Glazman W3C CSS Working Group, Co-chairman

• Anonymous
  May 11, 2010
  Hi Daniel, We've already posted a follow-up to this. Please see our updated post as of this morning.

• Anonymous
  May 11, 2010
  I support microsoft original decision why? There are many reasons why but to keep it simple, if Microsoft's intent is to support "EXACTLY" how another vendors prefix works then it should work. How often is a vedor going to actually change that functionallity for it to break compadiblity? But let me be clear I also think for someone who specifically does not want it to work there should be a way to turn it off. Something like a css-vendor-impersionation = false. That way those who want strictor then strict support have that, and for those who just want compadibility and for things to work it will. Who cares if Microsoft, Moz, or Apple wants to make webpages work exactly the way another browser implements a feature in their browser, it's to make the web a better place.

• Anonymous
  May 25, 2010
  I am developing applications using the Service-Now platform. We were previously using the Honeywell Dolphin 9900 Scanner with wm6, and it was operating very successfully. We purchased a couple of the newer scanners offered by Honeywell, which are provided with a new version of the Windows Mobile browser, and it is causing numerous problems.

1. The new browser seems to adjust it's zoom after every page load, and in the process the intended focus gets lost. This particular page puts the cursor in the scan field at the end of loading. But the cursor gets lost after the zoom refresh occurs, rendering the scanner inoperative without manually clicking in the scan field to give it the focus back. This is a disaster.
2. During each page load, the browser covers up a crucial region near the top of the page with the explorer bar, which takes several seconds before it times out and disappears again. This greatly reduces the efficiency of the individual trying to scan multiple items. I need to find a way to turn this off.
3. The menu button also covers up some content on the page. Can't we get all visual obstacles removed from the web page area? This is intended for content, not windows browser controls. There seem to be very few configurable options for the browser. Are there ways to modify the behavior through the registry? Thanks in advance for any help or advice.

• Anonymous
  January 07, 2011
  Is there any place where I can get the details of the final JavaScript interpreter implementation? I'm not sure why you're not at least on JQuery's B-list if media queries are in fact working properly. Once I get the emulator running, I can look at it myself but documentation would still be nice. Also, if the emulator can be run independently of Visual Studio Express 2010 and XNA Game Studio, being able to locate a download for just that would have saved me a lot of time today. On that note, I'd recommend QAing the installer for the dev tools when you leave VS 2008 Professional open, close 2008 and then reattempt. Not sure why you couldn't just pause the process rather than start all over again or just check if a version of VS was open from the start and tell the user to close it before continuing. Also, I believe a flag gets stuck in the registry causing reattempts to fail. I had to find the right advice which was to move the download executable to another location before trying again which worked. This was on Windows 7 if it matters.

• Anonymous
  January 11, 2011
  Hi Erik, We'll pass that feedback along. Just to be clear, Media Queries are not yet enabled for WP7 - that will be coming in a subsequent update. Right now, you can use conditional comments, which are covered in another post.