Microsoft and attributes--will they ever figure them out?
in [JavaScript]
|
Prev: What is a software engineer?
Next: Java Front end Developer | NYC | Long term (Only GC/Citizens)
From: kangax on 25 Nov 2009 12:42 David Mark wrote: > On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: >>>> David Mark wrote: >>>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> [...] >> [snip] >>> Those grading charts must be of great comfort to the end users who are >>> stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in >>> that Blackberry of yours (NetFront?) >> Blackberry browser is default browser for Blackberry device. It is a >> totally unique browser with its own rendering engine. >> >> Javascript is turned off, by default. Older versions of Blackberry >> shipped with CSS off by default. >> >> It has some really weird javascript bugs in it, some very undesirable >> behavior with respect to DOM recalc (it skips many), but has decent DOM >> support and pretty good support of ECMA-262 r3. > > That's why you have to test whether style changes affect the DOM > immediately and as expected. If not, you skip any enhancements that > rely on that happening. > >> The most interesting ECMAScript bug was recently found in Blackberry. >> The bug? Activation/Variable object has a [[Prototype]]. > > That is interesting. I talked about it here: <http://yura.thinkweb2.com/named-function-expressions/#activation-object-in-blackberry-browser> (this peculiarity was found by Garrett recently in one of the threads here, when we were trying to figure out if any browsers implement Activation Object as an instance of built-in `Object` constructor). > >> I added a link in the FAQ some time back to Blackberry Browser >> JavaScript Reference:http://jibbering.com/faq/#browserResources >> >> The Blackberry device is Java, so Opera Mini would be an option for that >> device. > > Good. Maybe they will switch to that. :) There are rumors of Blackberry switching to WebKit in a very near future (given recent acquisition of Torch Mobile � makers of webkit-based Iris browser � by RIM). <http://www.theiphoneblog.com/2009/08/24/competition-blackberry-browser-webkit-torch-mobile/> <http://wapreview.com/blog/?p=4935> There's no point in developing yet another proprietary engine. If they do adopt webkit, Blackberry browser will probably disappear in a couple of years (given its already low share among other giants like iPhone and Android � both webkit-based as well :)) > >> To run Blackberry Simulator, you need Email and MDS and then one or more >> Simulators. >> >> https://www.blackberry.com/Downloads/ > > Page not found. :( I would like to see the results posted for this > device. Which results? -- kangax
From: kangax on 25 Nov 2009 12:43 David Mark wrote: > On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: [...] >> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'is not >> 'images/cinsoft.gif' >> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'is not >> 'images/cinsoft.gif' >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is >> not 'images/cinsoft.gif' >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is >> not 'images/cinsoft.gif' >> >> Passing "2" flag to getAttribute doesn't seem to help. >> `getAttributeNode(...).value` and `attributes[...].value` report >> absolute values as well. > > Yes, those are things that you might try. So, if you need all > attributes to be 100% consistent across all browsers, you've got to > have a lot of feature tests. Thankfully this is a (very) rare design > requirement. In an HTML DOM, the typical app has no need to query, > set or remove attributes "manually". That's what the DOM properties > are for. But properties are not "reliable" either in case of older Opera (URL values are always reported as absolute, independent of whether they are accessed as properties � `.src` � or attributes � `getAttribute('src')`, etc.) > > An example would be a CSS selector query engine. That's one reason > why those are ever-shifting bad ideas. With the "major" libraries, > virtually every time a new browser comes out, their unit tests break > (assuming they have anywhere near enough tests and know how to > interpret them). In the minds of the authors, this invalidates the > old browsers rather than their backwards design decision to hang > everything on attributes. So they just "degrade" the old browser on > paper (browser grading), rather than in the code. :( I thought those charts are representative of QA testing. Yes, we can develop apps that degrade gracefully, but you still need to test things and testing takes time. [...] -- kangax
From: Garrett Smith on 25 Nov 2009 14:46 kangax wrote: > David Mark wrote: >> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>> David Mark wrote: >>>> On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: >>>>> David Mark wrote: >>>>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [snip] >>> >>> The Blackberry device is Java, so Opera Mini would be an option for that >>> device. >> >> Good. Maybe they will switch to that. :) Well, if "they" means the end user, that is an option. Blackberry users are allowed to use their hardware. Contrast to the iPhone, which is locked. Fennec, which could run in iPhone, cannot be used in iPhone because Apple monopolizes the App Store and won't allow it. Apple SDK also prevents developing scriptable applications, so no scriptable browser. > > There are rumors of Blackberry switching to WebKit in a very near future Yes, I have heard those rumors. Does Iris uses a proxy, like Opera Mobile? > > There's no point in developing yet another proprietary engine. There may be a point for keeping Blackberry. If Blackberry is more efficient, the battery would last longer. With a smaller app footprint, the browser will launch faster. There may be other reasons related to the device hardware or OS. The problem with browsers in touchscreen mobile I've tried is that they have the pointing device (finger) scroll the viewport. This copies iPhone. It breaks text selection, d'n'd, and overflow: scroll (among other things). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 25 Nov 2009 19:56 On Nov 25, 12:43 pm, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: > [...] > >> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'isnot > >> 'images/cinsoft.gif' > >> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'isnot > >> 'images/cinsoft.gif' > >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is > >> not 'images/cinsoft.gif' > >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is > >> not 'images/cinsoft.gif' > > >> Passing "2" flag to getAttribute doesn't seem to help. > >> `getAttributeNode(...).value` and `attributes[...].value` report > >> absolute values as well. > > > Yes, those are things that you might try. So, if you need all > > attributes to be 100% consistent across all browsers, you've got to > > have a lot of feature tests. Thankfully this is a (very) rare design > > requirement. In an HTML DOM, the typical app has no need to query, > > set or remove attributes "manually". That's what the DOM properties > > are for. > > But properties are not "reliable" either in case of older Opera (URL > values are always reported as absolute, independent of whether they are > accessed as properties `.src` or attributes `getAttribute('src')`, > etc.) The DOM properties interpret the attribute values. In the case of URI's, you get the full path (in all browsers). That's why you can't use properties - for example - to write an innerHTML emulation. > > > > > An example would be a CSS selector query engine. That's one reason > > why those are ever-shifting bad ideas. With the "major" libraries, > > virtually every time a new browser comes out, their unit tests break > > (assuming they have anywhere near enough tests and know how to > > interpret them). In the minds of the authors, this invalidates the > > old browsers rather than their backwards design decision to hang > > everything on attributes. So they just "degrade" the old browser on > > paper (browser grading), rather than in the code. :( > > I thought those charts are representative of QA testing. Yes, we can > develop apps that degrade gracefully, but you still need to test things > and testing takes time. Whatever they represent, the explanations for the results are often wrong. That indicates they are observations without understanding. That's fine for a QA tester, but no way for a programmer to approach browser scripting. So, not completely useless, but I'd rather test for myself.
From: David Mark on 25 Nov 2009 20:25
On Nov 25, 12:43 pm, kangax <kan...(a)gmail.com> wrote: [...] > > But properties are not "reliable" either in case of older Opera (URL > values are always reported as absolute, independent of whether they are > accessed as properties `.src` or attributes `getAttribute('src')`, > etc.) If by reliability you mean cross-browser consistency, then yes they are perfectly reliable (and all you should need for most apps). The point of all of this is that jQuery and other garbage dumps call get/ set/removeAttribute (e.g. the attr method). In some cases, there is no attempt to normalize the results at all, creating a very wobbly foundation for basic DOM scripting. More often, there are attempts to work around broken implementations, but the logic is either wrong or incomplete. These workarounds change from one version to the next as additional observations are made, which leads to more upgrades and incompatibilities with existing apps. In short, it's a God-awful mess that could have easily been avoided with a little understanding. And the first thing to understand is that you don't often need these methods in an HTML DOM. |