30534 - hasFeatures not showing support for CSS, CSS2 and Events

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[martin]

<script language="JavaScript"><!--
features = new Array('HTML', 'Views', 'StyleSheets', 'CSS' ,'CSS2', 'Events',
'UIEvents', 'MouseEvents', 'MutationEvents', 'HTMLEvents', 'Traversal', 'Range');

output = '';
for (var i in features)
    output += features[i] + ' - ' +
document.implementation.hasFeature(features[i],'1.0') + '\n';
alert(output);
//--></script>

Which shows:

HTML - true
Views - false
StyleSheets - false
CSS - false
CSS2 - false
Events - false
UIEvents - false
MouseEvents - false
MutationEvents - false
HTMLEvents - false
Traversal - false
Range - false

Although I beleive that DOM2 Events is only 80% surely it should be supporeted
in hasFeatures()?

Comment 1

[Gervase Markham [:gerv]]

Confirming using 20000511, upping severity. I'll attach the file.

vidur - could you have a glance at this?

Gerv

Comment 2

[Gervase Markham [:gerv]]

Attachment: JS in comment as a .html

Comment 3

[ekrock's old account (dead)]

Nominating nsbeta2. The whole point of hasFeatures is to provide a way for 
JavaScript code to determine what functionality is available. It would be nice 
if we returned accurate information for FCS. ;->

Comment 4

[Johnny Stenback (:jst)]

This one's mine.

I update hasFeature() some time ago, currently we report that we support

  XML (DOM versions 1.0 and 2.0)
  HTML (DOM versions 1.0 and 2.0)
  Views (DOM versions 2.0)
  StyleSheets (DOM versions 2.0)
  CSS (DOM versions 2.0)
  CSS2 (DOM versions 2.0)
  Events (DOM versions 2.0)
  UIEvents (DOM versions 2.0)
  MouseEvents (DOM versions 2.0)
  HTMLEvents (DOM versions 2.0)
  Range (DOM versions 2.0)

but according to joki we should not say we support UIEvents, so that needs
to be removed.

Comment 5

[leger]

spoke with ekrock - Putting on [nsbeta2-] radar. Not critical to beta2.

Comment 6

[Johnny Stenback (:jst)]

We should make this change for beta3 tho, we don't wanto give false info to the
callers of hasFeatures(), and the risk in this change is practically
non-existent.

Comment 7

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 8

[Johnny Stenback (:jst)]

Fixed.

Comment 9

[Hixie (not reading bugmail)]

Taking QA Contact on all open or unverified DOM Style bugs...

Comment 10

[Sivakiran Tummala]

still shows 
HTML - true
Views - false
StyleSheets - false
CSS - false
CSS2 - false
Events - false
UIEvents - false
MouseEvents - false
MutationEvents - false
HTMLEvents - false
Traversal - false
Range - false

reopening the bug

Comment 11

[Fabian Guisset]

The reason it shows all these false is because hasFeature() is called with the
1.0 version. However all of those modules are defined in the 2.0 version only.
Should we close this bug again?
IMHO the hasFeature() bugs have been around for too long (bug 62673, bug 63345)
and we should decide at some point.
Summary: Currently the situation is as follows
XML and HTML 1.0 and 2.0 : true.
Core 2.0 : false
Views 2.0 : true
StyleSheets 2.0 : true
CSS 2.0 : true
CSS2 2.0 : true
Events 2.0 : true
UIEvents 2.0 : false
MouseEvents 2.0 : true
MutationEvents 2.0 : false
HTMLEvents 2.0 : true
Range 2.0 : true
Traversal 2.0 : false
I suggest the following changes, based on the two other bugs cited above.
Core 2.0 -> true
CSS 2.0 -> false
CSS2 2.0 -> false

Any thought? Should I add David Flanagan to the CC list (since he filed bugs
about hasFeature())?
Adding Ian because he has reacted about hasFeature() in the other bugs and
probably knows better what we support and what we don't.

Comment 12

[Fabian Guisset]

Er forgive me for this little mistake:
CSS2 2.0 returns false and not true.
The change suggested for CSS2 2.0 is thus not necessary.

Comment 13

[Boris Zbarsky [:bzbarsky]]

resolving worksforme.  We report "true" for the things we actually support (and
possibly some we do not support completely, but those are separate bugs).

Comment 14

[Sivakiran Tummala]

reopening bug. I used hasfeature() with version 2.0 and css2 returned false.
attaching testcase.

Comment 15

[Sivakiran Tummala]

Attachment: testcase attached

Comment 16

[Braden]

M18? Nominating mozilla1.0 to put this back on the radar.

Comment 17

[Sivakiran Tummala]

nominating for nsbeta1

Comment 18

[Fabian Guisset]

Setting target milestone to mozilla1.0 instead of M18, to make sure we review
the values returned by hasFeature() before 1.0. Even though this method is not
in widespread use, it would be good to agree on what we implement successfully
and what not ;-)
Reassigning to jst so that it no longer has the stupid reopened status.

Comment 19

[scottputterman]

ADT3 per ADT triage.

Comment 20

[Fabian Guisset]

Attachment: Proposal for the return values of the hasFeature() method.

This is my proposal for the return values of the hasFeature() method. It was
already submitted to Boris Zbarsky. I'm looking for ideas and feedback from
other people, or unimplemented features that I have overlooked. I want to be
able to stare at developers and say "we return true/false for this module for
the following reasons ..." (that's the goal, anyway).
Feedback is appreciated :-)

Comment 21

[Hixie (not reading bugmail)]

We'll always have some bugs. I wouldn't use that as a reason to not say we
support a feature. Even the CSS feature is in reasonable shape now that bz,
caillon et al have been whacking it.

So IMHO we should say we support all the features except those for which we have
made no attempt.

Comment 22

[Fabian Guisset]

It is one thing to have bugs. It is another to have unimplemented interfaces.
From http://www.w3.org/TR/DOM-Level-2-Core/introduction.html#ID-Conformance:
"An implementation conforms to a DOM Level 2 module if it supports all the
interfaces for that module and the associated semantics".

But then again, it's true that returning false because of one or another
interface that nobody cares about...

Thanks for the feedback Hixie :-)

Comment 23

[Boris Zbarsky [:bzbarsky]]

> * CSSFontFaceRule is not implemented.
> * CSSPageRule is not implemented.

These are not implemented in the style system, so there is no way to do them in
the DOM.  Since the only way they arise in the DOM is via being in a sheet and
they can't be in a sheet because the CSS parser drops them, I'm not sure they
should affect the value returned

> * CSSImportRule is not implemented.
> * CSSCharsetRule is not implemented.

I just checked, and it sure _looks_ like these are implemented...

Comment 24

[Fabian Guisset]

I hadn't read the full description of the CSSCharsetRule and CSSImportRule,
sorry. Guess I can get rid of those.
About the other two, I guess people don't care if the style system doesn't
implement them. The fact is that we don't support those interfaces. But then
again, the question is,
do we want to return false for a whole module just because of a few non-critical
unimplemented interfaces. Heikki and Hixie say no, so far.

Comment 25

[Ray Whitmer]

Attachment: Add Core 2.0 and CSS2 to the list of features which we claim to support.

Add CSS2 2.0 and Core 2.0 to the list of "true" features.  This means that we
claim to implement these modules.  If there are known bugs in these features
(and there are including an occasional missing item) we agree to acknowledge
them as bugs and will make sure they are logged as bugs against the module,
even if we have no current plans to fix them due to the difficulty.

The same holds true for all modules on the total current list of supported
features (according to the hasFeature function):

HTML 1.0
HTML 2.0
XML 1.0
XML 2.0Views 2.0
StyleSheets 2.0Core 2.0
CSS 2.0
CSS2 2.0
Events 2.0
MouseEvents 2.0
MouseScrollEvents 2.0
HTMLEvents 2.0
Range 2.0

Comment 26

[Ray Whitmer]

I request a r= and sr= so that I can commit these changes today.

There is no significant risk in the code changes themselves, as we are just
adding checks to a list that works.

There is some risk to returning true, telling web pages that we support these
features, because it means that web pages that care to check (a simple search in
google found 1000 that  care about core 2.0, 400 that care about CSS (which we
did not change), 100 that care about CSS2) will suddenly start using these
features, which we know are not perfect in their implementation, but we believe
are quite well implemented and we are willing to fix as necessary to make them
as compliant as is practical.
We can neither take proper advantage of our support for these standards nor
reasonably receive feedback about any deficiencies, if we do not claim to
support them as is enabled by this patch.  We have waited long enough.

Comment 27

[Hixie (not reading bugmail)]

r=hixie, fwiw

Comment 28

[Johnny Stenback (:jst)]

Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

sr=jst

Comment 29

[Fabian Guisset]

I would have liked that everybody (or a majority, at least) agrees on the
returning values before proposing a patch. But if the netscape people want to
take on this, I submit.
Note that the current returned values don't even make sense, as pointed out by
Martin Honnen in the newsgroups:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-mouseevents
specifies that an implementation can only claim to support "MouseEvents" if it
fully supports "UIEvents".
/me bahs

Comment 30

[Ray Whitmer]

I am trying to help out getting some important stuff landed for Mozilla 1.0 to
give it appropriate exposure.  It is obvious that I am in a bit of a rush but
not such that if you have any reservations about the two features we are turning
on we won't resolve it before getting driver approval and checking in.

As for the two event types you bring up, which I did not propose to change in
this patch, your recent comment exactly contradicts your "Proposal for the
return values of the hasFeature() method, where they exactly match the current
implementation, which I am not changing.  I quote:

Feature name: "UIEvents"
Level: "2.0"
Return value: false
Comment: Reasons why false is suggested:

    * The interfaces are not implemented.

Feature name: "MouseEvents"
Level: "2.0"
Return value: true
Comment: Reasons why false might be returned:

    * No reason.

I wasn't aware of the thread you link to, nor am I inclined to go beyond the two
features which there seems to be a fair amount of agreement on.  If not, please
state your objections.  Everyone I have talked to seems quite willing to accept
them, but I was hoping you would respond here if you had new issues with them.

Comment 31

[Fabian Guisset]

your help is of course appreciated.
my proposal was just that, a proposal. It was far from perfect, as proved by
your patch (and hixie/heikki's comments), boris' comments, and martin honnen's
comments in the newsgroups. I did it to start the discussion.
I should have added a summary of the discussion in the newsgroups, sorry about
that. Anyway I'm fine with the patch, provided other people are. 
Maybe we should look at the MouseEvents issue though.

Comment 32

[Johnny Stenback (:jst)]

Ok, so I spoke to Tom (the main editor of the DOM Events spec), and his claim is
that the feature string "UIEvents" is supposed to flag support for the events
"DOMFocusIn", "DOMFocusOut", and "DOMActivate". The fact that the spec says that
in order to support the "MouseEvents" feature an implementation must also
support the "UIEvents" eature is an error in the spec that Tom was not aware of,
and he did not make that mistake either, one of the other editors most likely
did. Tom's working on what to do about that in the DOM specs.

I'd say for now we take Ray's change and leave the rest as is since the only
reason for changing what we return for "UIEvents" or "MouseEvents" might very
well end up being an errata for the DOM Level 2 Events specification, or changed
in DOM Level 3 Events.

Comment 33

[Asa Dotzler [:asa]]

Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 34

[Ray Whitmer]

The patch for core and css2 has now been committed.  It remains to be seen
whether we:

1.  Leave UIEvents / MouseEvents alone.
2.  Change UIEvents
3.  Change MouseEvents
4.  Fix the Events specification

I think we are leaning towards 4.

Comment 35

[Asa Dotzler [:asa]]

Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

obsoleting patch since it has landed.

Comment 36

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 37

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 38

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 39

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

File followups if we're mad enough to add more of these.