Meeting minutes
present_
space trimming in the context of text/tspan
karlcow: We have different behaviors between browsers but that isn't the main issue: the spec is not clear.
karlcow: We have different behaviors between browsers but that isn't the main issue: the spec is not clear.
karlcow: There is a part of the spec that suggests to follow CSS for spaces.
karlcow: later on in the spec there xml:space property which has 2 values: a default and preserved.
karlcow: the default value will remove all space, newline characters
> First, it will remove all newline characters. Then it will convert all tab characters into space characters. Then, it will strip off all leading and trailing space characters. Then, all contiguous space characters will be consolidated.
<karlcow> https://
<karlcow> 'default'
<karlcow> (The initial/default value for ‘xml:space’.) When xml:space="default", the SVG user agent will do the following using a copy of the original character data content. First, it will remove all newline characters. Then it will convert all tab characters into space characters. Then, it will strip off all leading and trailing space characters. Then, all contiguous space characters will be consolidated.
karlcow: this is contrary to what CSS is doing.
karlcow: I wonder if we want to keep xml:space or should we remove because of confusion?
krit: xml:space is use quite a lot
karlcow: the default or preserve?
krit: I see it with preserce
krit: I see it with preserve
karlcow: I agree with preserve for compatibility
karlcow: It should mimic CSS white space collapse?
Vinay: We have both in Chrome
krit: do they behave differently?
Vinay: need ot check
dmangal: We used to have SVG 1.1 xml:space and xml:space preserve. For 2 we kept both for compatibility but added white space from CSS
karlcow: yes
dmangal: So for xml:space preserve we following the CSS white-space properties behavior?
karlcow: I looked in the webkit code. There is specific handling for white-space.
karlcow: E.g for return, CSS is preserving, SVG is removing it IIRC
karlcow: E.g Firefox differs to WebKit and Blink
karlcow: Return keys are preserved in Gecko though the spec says not to preserve it for xml:space default
krit: What about multiple returns.
karlcow: the spec says it should collapse all into one.
karlcow: Gecko is not collapising multiple returns into one. Blink does seem to do it
<viralipurbey> https://
krit: Do we have a table with all differences across engines?
karlcow: I can create one if that helps?
viralipurbey: So it is only the XML side that is not aligned, right? So we deprecated it anyway.
viralipurbey: I also added a link from cSS WG which talks about how preserve is suppose to work
karlcow: So it is defined in CSS 4
karlcow: The issue I have is the confusing text in SVG2. IMO we should remove all prose and link to CSS spec.
Vinay: I am concerned with backwardscompat. The xml:space preserve behavior would slightly change.
<krit> s/Vinay /dmangal
dmangal: So we would see differences in older SVG space behavior.
karlcow: We need to see how often it is used in the web
krit: Most content is getting created by creator tools like Illustrator or InkScape. SVG is a transition format. So many web applications also rely on the current behavior.
karlcow: Go CSS WG and request adaption on white-spaces maybe?
karlcow: If there is a lot of content with xml:space, then we should make sure the CSS white-space is respecting the same rules in SVG. Only for SVG.
viralipurbey: I was going throught the CSS logs and saw that the preserve was designed in a way so that SVG can use it. There are smaller differences but they are interested in aligning.
krit: so similar to karls comment: get back to CSS WG?
karlcow: I think the first step would be to complete the matrix to have a better understanding what is happening.
ACTION: karlcow will create the matrix of all xml:space/white-space behaviors across engines
ACTION: Vinay check use counter for xml:space preserve/default
karlcow: If you have ideas about corner tests, add those to the github issue
ACTION: Eveyone: think about corner tests for spacing
Behaviour of :percent spatial media fragment in SVG when no natural size is given for the external image
dmangal: I logged it but believe to have a resolution
dmangal: We support media fragments in SVG. Spatial :precent
dmangal: the flavors of media fragements have pixels and percentage.
dmangal: If we can use the intrinsic values for percentage. That would work. Robert suggested to follow the cSS specs default 250
dmangal: this is what Firefox does. Should we follow the default values as Firefox?
karlcow: rendering in Webkit is the same as blink
karlcow: but both are not aligned to Firefox?
dmangal: correct. IMO we should follow the CSS text (and Firefox)
viralipurbey: with intrinsic you mean the viewbox of the SVG?
dmangal: the width and height
viralipurbey: so the specific width and height?
dmangal: yes
krit: So lets agree to follow CSS spec?
<karlcow> https://
RESOLUTION: For spartial media query :percentage, use the CSS specified default width/height 300:150
<dmangal> 300x150
<viralipurbey> 300 * 150
16.3.2 fragment grammar vs. implemented handling of svgView() combined with xywh= (and other disallowed combination
dmangal: Interaction between different fragment identifiers.
dmangal: what happens if spatial media quearuies and fragment idenitfiers are specified together?
dmangal: Chrome and Safari ignore spatial fragments
dmangal: Firefox only implements the spatial part but not the second part (other fragments)
dmangal: the interaction between these is not clear in the spec.
karlcow: Firefox just landed a fix 6 ays ago
<karlcow> https://
karlcow: svgView spec followed by a time spec
<karlcow> Allow SVGViewSpec to be followed by a timesegment
dmangal: it was missing but not directly related to the issue from karlcow
krit: IIRC svgView hasn't been used much
karlcow: because it never was implemented reliably
viralipurbey: what should be the 3 possible solutions we follow?
<karlcow> Option 1 — tighten the grammar (status quo of the spec). Add explicit normative prose:
<karlcow> Option 2 — relax the grammar.
<karlcow> Option 3 — codify one of the lenient parses.
viralipurbey: Robert was leaning to option 1
viralipurbey: dmangal too
dmangal: yes
dmangal: time fragments with those can be combined.
dmangal: anything apart from that should get rejected
dmangal: or in roberts words: the spatial fragements should get rejected.
dmangal: only the combination of spatial fragments cross non-temporal fragments should get rejected
TPAC
karlcow: Any one planning to go to TPAC?
karlcow: If we have a critical mass, we should have an SVG WG meeting
RRSAgent> , make minutes
RRSAgent: make minutes