David said:
Okay. But it is what I go by. If it won't validate there,
I don't use it.
Maybe you don't, but a pragmatic approach might say that if you want
consistent behaviour on IE versions <= 5 (as 6+ is fine with 'pointer')
then the fact that standard CSS implementations are required to handle
the unrecognised property value in a particular way give you an
inexpensive means of achieving that consistency without breaking
anything.
[snip]
The last brand new mobile phone I encounter that shipped with
Opera 6.12 installed was around the new year, so given the
turnover of mobile phones may 'we' can forget about it now.
That's good.
Bear in mind the reason that Opera 6 was still being embedded in mobile
phones as recently as the start of this year (and may well still be). It
is because it is very small. Operas 7-9 are also very small in
comparisons to leviathans like Mozilla, but not as small Opera 6.
The devices into which browsers are embedded are becoming more capable
and have more resources available to them, so the need for very small
browsers diminishes, but at the same time browsers are starting to be
embedded into even smaller devices. I have seen proposals to embed
browsers into watches. I am not sure how that is going to work out (how
useable they could ever be), but that trend may suggest that there may
be an ongoing demand for small-footprint, well tried and reliable web
browsers, and so Opera 6 may be with us in one form or another for a
little while to come.
And I think it is NetFront.
It is.
Regardless, what is that one used for?
PDAs and mobile phones
Sounds like a decent test.
It is the making of assumptions that undermines the effectiveness of
feature testing. this strategy is not assumption-free.
Well, only in this simplistic example. You could wait until
the body is loading and then insert the style element into
the DOM once you check if the body's display style is a string.
You could, but if the test were applied to the elements that were to be
hidden (as the probably should be) it would be easier to just set
their - display - properties directly on the element's style object and
forget about adding style elements.
I think it is likely that they do, regardless of how illogical
it is.
It is not a question of the testing being illogical, it is not. Given
that the majority of browsers are written in C++ (or another class-based
OO language) the odds of the element objects all possessing exactly the
same type of style object are extremely high (it would almost be
irrational to do anything else). The issue is with the principles of
feature detection, where the ideal test has a one-to-one relationship
with whatever it is that needs to be known form the test. Testing the
style object of the HEAD or HTML element in order to make decisions
about how to treat elements within the body is more testing a parallel
relationship. That is still much better than an object inference test,
and most parallel relationships do hold in reality, but it is not ideal.
The issue of the possibility that non-displayable elements would have
different - style - object implementations to displayable elements.
Nobody has been able to point to a single environment where they do, but
as nobody can be familiar with the DOMs of all scriptable browsers that
does not indicate that there is no issue.
The possibility of the head and body having different
types of style properties?
Yes.
I insist I am not using an "object inference."
Insist away, it won't change anything.
Maybe for a very good reason.
but actually the test to write the style sheet is just a
bookend for the test used to run the script that will
ultimately show the hidden elements.
That is the inference. You are inferring that the existence of the -
getElementById - method of the document implies the ability to override
a STYLE element applied CSS rule by assigning to the - display -
property of an element's - style - object. If you are wrong in that
inference your script will act to render the content hidden by the STYLE
element you write completely inaccessible. That is the worst possible
outcome of a scripted action, and the reason why a much better test, or
alternative strategy, would be appropriate.
I know that gEBI doesn't indicate anything about whether
style properties can be maniupulated.
No it doesn't, but the decision to write the style element needs to
relate to the ability to dynamically manipulate the style properties,
because once written it cannot be unwritten (at least in any environment
where the styles could not be dynamically manipulated).
The aggregate result of the two tests has been shown not to
work in Opera 6 and perhaps some older mobile phones.
Not to work in browsers that do not provide a dynamic DOM.
As we have been over, this example will never be perfect.
Maybe not, but a script that may acts to render content inaccessible is
suffering from a fundamentally flawed design.
Personally, I wouldn't hide the answers in a FAQ at all.
The whole thing is silly, but that is what
the OP wanted to do.
It strikes me as a silly gimmick, but it doesn't need to be a silly
gimmick that will act to interfere with the reliability of the
underlying HTML.
Yes. I had to do lots of similar things to make positioning
work to the pixel across the various major browsers without
resorting to browser sniffing.
I actually thought about discussing such a test earlier in
the thread, but it seems beyond the scope of this dynamic
FAQ example.
Don't let the Subject headers of threads (or the subjects of the OPs)
fool you into limiting the scope of any discussion. The only criterion
for on or off topic is the topic of the entire group
(javascript/ECMAScript). Threads are supposed to wander wherever the
discussion takes them (one of the reasons branching threading is such an
integral part of Usenet, as such discussions don't really make sense in
a chronological/linear presentation).
Also, you couldn't use document.write for the style,
That is pretty much the crux of criticism of the strategy.
so the whole example would
have to changed to use the DOM.
Not if there was no STYLE element involved, and there dos not have to
be.
I realize all of that, but if the FAQ is going to hide all
of its answers, it doesn't look very good to have them
flash at the outset.
They could only flash on browsers that do progressive rendering as the
page loads (which is a long way from being all browsers). It is a
possible minor display glitch, so probably not something that you would
want to sacrifice the viability of the end result to.
I know how to get around this, but again, I think that the
solution is beyond the scope of this simple example. In short,
you would want to avoid using onload to hide the elements, so
you would have to use DOMContentReady if available and simulate
it for IE.
I don't see what you mean by "trueness."
In javascript 'trueness' is attributed to any value that would result in
boolean true if the type-convert-to-boolean rules were applied to it (or
is boolean true to start with). That is, a value that is not necessarily
boolean true itself but will act as boolean true in any context that
implies the type conversion.
I think checking for a string type is what we are after.
The subject of my 'trueness' requirement was the value of the - style -
property of element. That is all that is necessary in the strategy
outlined above because without trueness - el.style.display =
'whatver'; - will error-out, while with trueness it cannot. Because the
strategy first hides the element before attempting to reveal them it no
longer matters whether the assignment itself is effective as its
possible ineffectiveness will not move the page away from a viable
state, while the code actually erroring-out remains something to be
avoided.
Typically it will be an empty
string, which converts to boolean false.
The - display - property of the style object, not the element's -
style - property.
I realize that. What I meant was that there are a lot of
applications out there that hide elements initially.
There is a world of difference between a web application and a web site.
Virtually anything that uses
popup menus falls into this category.
Most actual instances of popup menus do not appear in contexts that
should ever be considered web applicaitons.
So all of these pages are susceptible to this weird
Opera 6/NetFront bug.
It is not a bug. The display in User Agents is not mandated to be
updated, re-flowed, or re-drawn in response to modifications in the DOM
presented to scripts.
I am not particularly concerned about it as I rarely write
apps that hide elements initially, but many do and there
would seem to be no simple recourse.
It is the people writing web sites and e-commerce sites that need to be
worrying about how there script design strategies impact on viability of
their creations. For web applications the design criteria can be very
different.
The next time I need to write a page with popup menus,
I will use the DOM to insert the style element,
If you insist upon using a STYLE element at all.
but that won't fix the millions of
pages that use document.write to do this.
Nothing will fix the millions of pages where unconsidered/uninformed
script design decisions have fatally undermined the fundamental
viability of the underlying HTML. That is not really an excuse for
promoting the creation of more of them.
Many of them don't even take that precaution, they just
make the hide style static, as seen in a recent menu
question posted here.
Yep, no matter how badly anything may be seen to be done there is almost
always potential for doing it worse.
Interesting as my next question would be whether position and
visibility are on that list.
I explicitly stated that - visibility - is in the list. The - position -
property is not, as switching that would require/imply a re-flowing of
the document. But the - position - property was not dynamically
assignable on IE 4, even though it had that property exposed on the
style object.
It sounds like they are not as modifying
the position style would require a document re-flow.
It would.
It is a good thing that Opera 6 is now virtually extinct.
If it is.
How widespread is this NetFront thing and are there others
that behave like this?
It is hard to say as it would invariable be listed in browser statistics
as IE. It has been (or seems to have been, as it is not easy to tell for
sure) the browser embedded on about 60% of the new small devices that I
have had a chance to look at over the last year, though the last version
I had a chance to fully test was 4 and there seem be at least some
improvements in the latest versions.
Richard.
ointer;text-decoration:underline;color:blue}</style>');