Matching URI with an empty path and a fragment ID

[revad]

I noticed a difference when porting a style that worked in Stylish, and works in userContent.css, but does not work in Stylus. I think it is a bug in Stylus.

The ancient site mudcat.org contains links to within the page such as #BS and #top.

I had userstyles containing
@-moz-document url("http://mudcat.org/"),
url("http://mudcat.org/index.cfm")

The normal entry is just 'mudcat.org' (the /index.cfm links are generated by the 'refresh' button). If I hit the #BS link it goes to http://mudcat.org/#BS

@-moz-document url("http://mudcat.org/") does match that URI in Stylish and userContent.css

In Stylus it doesn't: clicking the #BS link unapplies the userstyle. I have had to add an extra match:
URLs starting with http://mudcat.org/#

This seems only to be an issue when the document path is empty. So if I click 'refresh' and then the #BS link it goes to http://mudcat.org/index.cfm#BS which does match.

An example userstyle is
https://userstyles.org/styles/136780/mudcat-reorder-index-columns
I added the extra match there too - only afterwards realising it must have worked without it.

• Browser:
  Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

[tophf]

Indeed, according to the CSS4 @document specification:

The URL of the document being styled is the URI at which the document is located, excluding any fragment identifiers.

This is a legacy bug from Stylish-for-Chrome. Will submit a fix soon.

P.S. On an unrelated note, @namespace is allowed only in the top context preceding any other rules such as @-moz-document according to the specification, meaning your code is invalid, strictly speaking.

[tophf]

Huh, conforming to the specification will kill the ability to apply style sections that target #hash URLs intentionally. OTOH it's more important to be spec-compliant. I wonder if it's worth "extending" Stylus so that it compares #hash parts in case it's specified in a style section... @narcolepticinsomniac, thoughts?

[tophf]

Test version with strict spec implementation: strip-fragment.zip
(#hashfragment is completely ignored when finding applicable styles).

[narcolepticinsomniac]

I wonder if it's worth "extending" Stylus so that it compares #hash parts in case it's specified in a style section...

I was familiar with the behavior, but not the spec. Makes sense. It doesn't come up that often, but I have had to make adjustments on rare occasions. OTOH, IIRC, I have also utilized this bug as a feature, at least a few times. No doubt we should adhere to the spec, but ideally we could also preserve the ability to override the new default behavior by maintaining the ability to exploit keying on fragments.

[tophf]

Do you think more than a couple of styles abuses the incorrect behavior to be able to target #hash URLs?

[narcolepticinsomniac]

If I say yes, will that help convince you that a hack is worthwhile? Realistically, it's probably not that common, but speculation as to exactly how uncommon wouldn't be anything but a wild guess.

[tophf]

Actually, I believe the specification is simply outdated. It was written just for Firefox, never adopted by the w3c, in those ancient times when there were no single page application sites that utilize #hash URLs instead of normal ones. So I'm inclined to leave our code as is. Otherwise a lot of styles that target Google search may break.

[narcolepticinsomniac]

Usually arguing against the spec is a lost cause with you. Not sure how to deal with that, so I'll play devil's advocate. Wouldn't complying with the kinda-sorta spec, but still allowing user overrides, not break Google styles and the like? Maybe I'm not considering all the possibilities. NBD either way, the status quo is also fine by me.