Skip to content

[css-typed-om] CSSURLImageValue #703

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
annevk opened this issue Feb 21, 2018 · 4 comments
Open

[css-typed-om] CSSURLImageValue #703

annevk opened this issue Feb 21, 2018 · 4 comments
Labels
css-typed-om-2

Comments

@annevk
Copy link
Member

annevk commented Feb 21, 2018

I'm pretty sure that some user agents parse URL values eagerly.

<!DOCTYPE html>
...<style>
body {
  background:red;
  background:url(https://test:test);
}
</style>
<script>
alert(getComputedStyle(document.body).backgroundImage);
</script>

Yields none in Firefox, url(https://test:test) in Safari, and url("https://test:test/") (!) in Chrome.

It seems rather crappy if new CSSURLImageValue("https://test:test") did not throw.
@tabatkins
Copy link
Member

I'm wondering if it would be worthwhile to reify it as an actual URL object. Tho I guess that doesn't support keeping relative urls as relative, or fragment references as fragment references.

@tabatkins
Copy link
Member

So here's the wrinkles:

  1. A url like url(#foo) must be kept as #foo exactly - fragment references are always parsed against the current document's URL, even if it changes, rather than being eagerly resolved against some particular base URL. (This allows frags-as-internal-references to always work regardless of whatever shenanigans you pull with the document's url.)

  2. A relative url like url(foo) is resolved eagerly against some particular base URL; in a stylesheet the base URL is the stylesheet's own URL. If we hew close to this, it implies we should keep relative urls unresolved, and only resolve them when the values are actually .set() into a rule somewhere.

We can maybe ditch (2) and just find some reasonable base url to resolve against. (I went looking for precedent and found that, whoops, it's just completely unspecified for the FontFace object. Filed w3c/csswg-drafts#2343.) In fact, it's probably better to do so - the base-url behavior in stylesheets is often kinda confusing, and having it vary based on exactly where you're setting would probably be confusing to authors.

(1) is at least easy to recognize - if it starts with a #, we can just leave it unparsed. That functionality is necessary, so we can't remove it.

@annevk
Copy link
Member Author

annevk commented Feb 22, 2018

We discussed (1) before. And I think we agreed that we would tag those as special values. Note that per https://url.spec.whatwg.org/#url-apis-elsewhere you don't want to use URL objects, but you should eagerly parse generally.

@annevk
Copy link
Member Author

annevk commented Feb 22, 2018

But yeah, I think you should sort out how this works in general as otherwise the object model might not match how style sheets work...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-typed-om-2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tabatkins @annevk @nainar