-
Notifications
You must be signed in to change notification settings - Fork 662
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.
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
[css-content] content property, <image> | <url> can be just <image> #216
Comments
fixed via cbdf6c6 |
These were called out separately because the url could in theory be other than an image, e.g. a sound file. |
Per the definition of <image>: if the <url> doesn't point to a valid image, then it needs to be handled as an invalid image, so, yeah, we explicitly need a <url> here for non-images. Also the there are inconsistent uses of the term URI vs URL throughout the document, recommend they all become URL. (edited to escape < as < —@zcorpan) |
Could it be turned into a @plinss Your comment misses the types. You need to code-format them to be displayed correctly. Sebastian |
Is there implementation interest in supporting sounds here? |
I noticed this when trying to draft up how this would attach to the Fetch specification, ideally knowing the content type ahead of the request would be better here. The issue with supporting sounds surely would require some clearer form of content negotation than just URL's right? For example using URL modifiers as per the spec to be something like this:
Where anything else is assumed images. For brevity the request types of fetch could be used instead:
Also the |
Yeah, lacking an actual definition of how we would content-negotiate non-image things, this should be specialized to |
https://drafts.csswg.org/css-content/#content-property
https://drafts.csswg.org/css-images-3/#typedef-image
Since
<image>
expands to<url> | ...
, there is no need to include<url>
as well when using<image>
in the Value grammar.The text was updated successfully, but these errors were encountered: