– DRAFT –
(MEETING TITLE)

naturalWidth and naturalHeight in the context of an HTML image

<karlcow> w3c/svgwg#1044

w3c/svgwg#1044

karlcow: SVG is used as an image in the src attribuite as an image.

karlcow: UA would fetch width and height from SVG if present. No issue then. But what happens when one of both or none is present.

karlcow: There is a different behavior across UIs for naturalWidth and naturalHeight. We are fixing issues on our side.

karlcow: What should be returned for document.querySelector('img').naturalWidth document.querySelector('img').naturalHeight

karlcow: SVG spec says auto which is 100%. But doesn't say anything about what happens if the attribute is not present.

karlcow: should auto be 100%? What is 100%?

krit: Doesn't CSS sizing spec define something as a default?

karlcow: There is withh 300x150

karlcow: There might be web compat issues. E.g if you have a super large with and maintain aspect ratio. It would create an image that does not fit the page... something very big

karlcow: In Chrome and Gecko, there is a limit up to which dimension can get displayed.

karlcow: If naturalWidth/naturalHeight is not available, there is a fallback defined. We should add a reference to the HTML spec in SVG spec what happens of an SVG image (with missing width/height) UA should follow the HTML spec.

krit: We would require a normative reference to the HTML spec. Unsure if we should do that. Can we define the same text in SVG?

karlcow: we could do, yes.

caribou: I am not sure if that is an issue that needs to get defined/fixed in the SVG spec.

caribou: though it does seem to be an compat issue.

karlcow: What is the concern with a normative reference to the HTML spec?

krit: IMO it should be part of the HTML spec to define what naturalWidth/naturalHeight even means for vector formats. But the SVG spec should define what it means in this context or at least provide context to the HTML spec.

caribou: we could define the aspect ratio

krit: aspect ratio is defined as part of the viewBox attribute.

caribou: it seems fine to let HTML spec define it

krit: If there is anything missing in specific context in the SVG spec, I am fine with being more specific in the SVG spec. At this point I am not sure if there is anything missing though.

caribou: lets keep the issue open and bring it back to the WAHTWG

ACTION: Karl will get back to WHATWG to ask if there is something missing with regards to naturalWidth/naturalHeight in the SVG spec

Bikeshed migration

karlcow: I continued to work on the conversion of the spec to Bikeshed and made good progress.

karlcow: 1/3 has been migrated

karlcow: Links to chapters are working already.

karlcow: There are still a few breakages with regards to markup but not much of a challenge

karlcow: My concern, is the XML file containing all SVG element definitions

karlcow: Bikeshed will get to the XML file, fetches the information and adds that to the Bikeshed content.

karlcow: I wonder if we want to do the conversion once: Migrate the XML to actual Bikeshed or if we want to add a pre-processing spec to read the information from XML.

karlcow: I suppose the previous bheavior with the XML document made sense. But on going, we might not want to keep it.

krit: I believe there were a use case to read and verify information beyond the spec but don't know what it was.

krit: Is there a way to extract element and attribute definitions from the Bikeshed document?

caribou: if yes, we could, if required, extract the information back from the Bikeshed spec.

ydaniv: Bikeshed does support import information from other specs.

ydaniv: Maybe you can ping Tab?

<karlcow> <edit:with element='rect'>

<karlcow> <edit:elementsummary name='rect'/>

<karlcow> https://github.com/w3c/svgwg/blob/c82ab6ad3e1e583744df6c553eb4150477ced399/master/shapes.html#L52

karlcow: could you sync with Cameron if there were other use cases for the XML file? Maybe the one time conversion is good enough.

<karlcow> https://svgwg.org/svg2-draft/shapes.html#RectElement

fetch priority to SVG script element

viralipurbey: Did we reach a conclusion on this topic or is the discussion still open?

<karlcow> https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20fetchpriority

<viralipurbey> w3c/svgwg#916

Minutes: https://www.w3.org/2025/12/18-svg-minutes.html

viralipurbey: When we supposed the feature to the owner, they were not keen to add this to the parser.

<Vinay> https://groups.google.com/a/chromium.org/g/loading-dev/c/abRvsaclp0Q/m/fjLyFZtqDAAJ - Chromium code owners are reluctant to expand their XML-Parser logic thus reluctant to add support for `fetchPriority` in SVG script elements.

viralipurbey: Chrome will not support the fetchpriority for now.

Vinay: Added a link in the chat to this discussion

viralipurbey: I am folllwing up on the action that I had. Our opinion is to not do it.

Vinay: It is highly unlikely that we will add that to chrome.

RESOLUTION: SVG will not specify the fetchpriority attribute on SVG Script element

RRSAgent: make minutes