[Webkit-unassigned] [Bug 83490] history pushState doesn't affect :target selector

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=83490

Brady Eidson <beidson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #6 from Brady Eidson <beidson at apple.com> ---
(In reply to comment #5)
> When location.hash equals an empty string
> how can document.querySelector(':target') be equal to an element?
> How is it true?!
> 
> The spec says that hashchange event shouldn't be fired
> But it doesn't restrict you in applying css styles.
> So basically the bug is valid and you won't fix it because you are lazy.
> This is true.

Since Archil contributed this respectful comment, engaging the community in a positive way, I took another look at this.

My most previous comment:

(In reply to comment #4)
> This is not a bug.
> 
> The state object is about session history, and not the actual URL of the
> document.

...was simply wrong.

It's always updated the Document URL (http://trac.webkit.org/changeset/51644) 

But does this automatically mean the CSS selector should be updated? 

I'm not sure. I know very little about the specific rules of CSS style recalc. It does appear in https://drafts.csswg.org/selectors-3/#target-pseudo that the document's URL should apply. But what I don't know is if pushState/replaceState themselves should actually trigger a style recalc...  but of course anything else that triggers a recalc would come along and refresh it...

I'll ask some CSS folks to help resolve this uncertainty.

But, in the meantime, NOBODY does this. I just tried:
-Latest Chrome (48.0.2564.103)
-Latest Firefox (44.0)
-Latest Edge (12.10514)
-IE11

And this doesn't work in any of them.

So even if we conclusively say "yes, this is the right thing", it's a compatibility concern.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160205/2d3b60d8/attachment.html>