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

Status: RESOLVED INVALID

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

Description

[mathieu]

Attachment: 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 :
el.id = 'target2b';
window.location.hash = 'target2b';

// does not works :
window.location.hash = 'target2b';
el.id = 'target2b';

Comment 1

[j.j.]

Attachment: testcase2 (simpler)

simplified, removed jquery cruft

Is this what you want to test?

Comment 2

[j.j.]

Any browser I'v on hand behaves as Mozilla (Chrome 20, Opera 12)

Comment 3

[mathieu]

@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?

Comment 4

[j.j.]

<shrug> no idea. Moving to Core/Layout. There are more capable people around (they are very busy and may hate me doing so ...)

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[mathieu]

I tried to explain the possible issue in this bug : https://www.w3.org/Bugs/Public/show_bug.cgi?id=19994

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 9

[Lea Verou]

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: https://codepen.io/leaverou/pen/YJPeOp

Comment 10

[Sean Voisen (:svoisen)]

Related spec bug: https://github.com/w3c/html/issues/235

Comment 11

[Boris Zbarsky [:bzbarsky]]

The relevant spec is https://html.spec.whatwg.org/multipage/

As of https://github.com/whatwg/html/issues/190 being resolved, I believe we match that spec.

The W3C fork may not have pulled in those changes, like so many other changes...