Closed Bug 773020 Opened 10 years ago Closed 3 years ago

:target not applied if id is modified to match uri hash with javascript


(Core :: CSS Parsing and Computation, defect, P3)






(Reporter: mathieu, Unassigned)


(Keywords: testcase)


(2 files)

Attached file test case
if a css rule apply some style to :target element, it's not applied if an element id is modfied in javascript to match uri hash

see test case in attachment

in short:

// works : = 'target2b';
window.location.hash = 'target2b';

// does not works :
window.location.hash = 'target2b'; = 'target2b';
Attachment #641182 - Attachment mime type: text/plain → text/html
Attached file testcase2 (simpler)
simplified, removed jquery cruft

Is this what you want to test?
Any browser I'v on hand behaves as Mozilla (Chrome 20, Opera 12)
Keywords: testcase
@j.j. yes that's what I want to test

the test with id(could have been class, [disabled], :lang, etc.) was to show that it was working with other selector

yes opera and epiphany have the same behavior. I still think this a bug, isn't it?
<shrug> no idea. Moving to Core/Layout. There are more capable people around (they are very busy and may hate me doing so ...)
Component: General → Layout
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 15 Branch → Trunk
It's not actually clear what the spec says here.  In particular, is the "indicated part of the document" that HTML5 describes as being used for :target matching computed when the URI is loaded, or every time :target is matched?

Probably worth raising this as a spec issue on HTML5.
I tried to explain the possible issue in this bug :
So a related question:  do the two scenarios in comment 0 behave differently in terms of whether the browser scrolls that element into view?  Should they?
> do the two scenarios in comment 0 behave differently in terms of whether the browser scrolls that element into view?

Yes, they do.

> Should they?

Good question.  To make them behave identically, every time an element with an id is inserted into the document we'd need to scroll to it if that was the current URI ref or something.  That seems user-hostile at best, not to mention the performance problems.
Component: Layout → CSS Parsing and Computation
Ever confirmed: true
I just stumbled on this bug while debugging a slideshow library that used :target for the current slide. 
This is the testcase I made, in case it's useful:
Priority: -- → P3
The relevant spec is

As of being resolved, I believe we match that spec.

The W3C fork may not have pulled in those changes, like so many other changes...
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.