CSS properties should apply to some SVG elements as well

[dirkschulze]

The white-space, letter-spacing, word-spacing properties should apply to SVG text as well. SVG2 doesn't specify which, but the likely candidate is text content elements. CC @AmeliaBR

https://svgwg.org/svg2-draft/text.html#LetterSpacingProperty

[fantasai]

@dirkschulze Should it be just those properties, or everything in the entire spec?

[dirkschulze]

@fantasai I tried to list those that are currently referenced by SVG2. In the future we should check every property if it could apply to SVG but currently restrict the elements they apply to.

[css-meeting-bot]

The CSS Working Group just discussed CSS properties should apply to some SVG elements as well.

The full IRC log of that discussion

<dael> Topic: CSS properties should apply to some SVG elements as well
<dael> github: https://github.com/w3c/csswg-drafts/issues/3414
<dael> astearns: Is AmeliaBR on?
<dael> astearns: Looks like krit is asking for some things to apply to SVG text
<dael> fantasai: Wanted to ask if we want to deal with them for all our specs. DOesn't make sense for a few prop. If we've got a case with some but not all we've got a case where if you don't spec a prop does it apply?
<dael> chris: That's not what we mean. We don't say it applies to HTML elements, we just say elements
<Rossen> +1 to what fantasai said
<dael> AmeliaBR: Reason it came up is...concern if we rely on SVG spec to mention which prop apply it will regularly get out of date as new prop introduced. Trying to move that into prop definitions and make sure it's covered byt he applies to part of prop definition box
<dael> AmeliaBR: As chris said in cases where we have applies to all elements it can presume to apply to SVG elements. But then there are some places it says applies to but it's CSS box type. It's about being consistent and making sure those boxes are useful
<dael> fantasai: All elements means all elements formatted with css box model. SVG has typicially been outside our spec zone. Incorporating which applies to what SVG makes sense. but if we're going to do it we should do it to all specs.
<dael> fantasai: If we want to do that we should resolve to do that for all specs at once so everything is consistent. And it goes in at once so there's no point where we've got uncertainly.
<dael> fantasai: That's what I'd like tos ee us do
<dael> AmeliaBR: Agree with that strategy. I think it should be thought of in conjunction with some other open issues about redefining how applies to line works. Open issue about if pseudo elements are in all elements
<dael> fantasai: They're not except before and after which in their own definition says that.
<dael> fantasai: I think if we list every pseudo element we could do that. before and after it would be redundant because they say they'r enot a special type.
<AmeliaBR> https://drafts.csswg.org/css-text-3/#word-spacing-property
<dael> AmeliaBR: Specific properties krit brought up, they say applies to inline boxes which is a very CSS term
<dael> AmeliaBR: That's where the issue for those came up. Might come to having to sit down and come up with a set of new terms that can be used for covering the SVG layout/element types as well as the CSS box types
<dael> AmeliaBR: That's prob. first step. A proposal for which categories to use for what makes sense to desc the SVG properites. Then come back to WG for confirmation and then make a giant PR
<dael> fantasai: Makes sense. DOn't rely on all elements to help you out, though. Border applies to all for SVG. We'll have to change things around.
<dael> AmeliaBR: It might change ell elements to all css boxes or something like that.
<dael> AmeliaBR: Not going to figure it out on the call. If anyone has ideas we can brainstorm in the issue. First step is figure out what hte categories should be that makes sense in both contexts.
<dael> AmeliaBR: Once that's decided it's going through every spec and making sure it makes sense
<dael> fantasai: Direction sound good to everyone?
<dael> chris: sgtm
<dael> fantasai: I'll tag this issue against all specs
<dael> astearns: I don't know if that'll be that useful. But mentioning in a comment this will apply to all specs might b sufficient.
<dael> astearns: How many SVG folks will be at F2F? I'm wondering if this is something we can noodle on
<dael> chris: I hope to be
<dael> AmeliaBR: I will be in person
<dael> AmeliaBR: krit though won't be around. not sure about myles or eric
<dael> astearns: Let's see if we can wrap this up by the F2F
<dael> astearns: Anything else on this issue?

[css-meeting-bot]

The CSS Working Group just discussed CSS properties should apply to some SVG properties as well.

The full IRC log of that discussion

<gregwhitworth> Topic: CSS properties should apply to some SVG properties as well
<gregwhitworth> AmeliaBR: I don't have a whole lot to update
<gregwhitworth> AmeliaBR: in comparison to the telecon
<gregwhitworth> AmeliaBR: the issue came up because we want an easier way for defining what applies to SVG instead of having to update every time a new CSS prop is added
<gregwhitworth> AmeliaBR: having to update the spec to say, "hey this also works" - some specs do this but it's not at all consistent
<gregwhitworth> AmeliaBR: the applies to in the definition is loosely defined
<Rossen> q?
<chris> rrsagent, here
<RRSAgent> See https://www.w3.org/2019/02/26-css-irc#T18-16-08
<gregwhitworth> AmeliaBR: when you look at CSSOM for getCOmputedStyle it has nromative impacts on whether you return the computed or used style
<gregwhitworth> AmeliaBR: I think this issue got added to the F2F that I would come with a pretty proposal but that hasn't happened
<gregwhitworth> AmeliaBR: In general I'd like to suggest that the applies to more rigorously defined which categories are used?
<heycam> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<heycam> q+
<gregwhitworth> AmeliaBR: as far as how it works on SVG side is, it shows all elements but is it ALL elements considering SVG?
<gregwhitworth> AmeliaBR: instead of using the term elements we can use rendering tree terminology, etc
<gregwhitworth> AmeliaBR: also others mix elements and rendering tree words it's very incosistent
<gregwhitworth> AmeliaBR: the SVG element the same element in different layout contexts may or may not have a CSS box
<gregwhitworth> AmeliaBR: another thing for SVG - text content elements many text related props will apply to SVG Text but not all
<gregwhitworth> AmeliaBR: because the actual text layout is different
<gregwhitworth> AmeliaBR: it would be valuable to not have to re-analyze if it impacts SVG text, etc
<gregwhitworth> fantasai: what are we trying to conclude
<gregwhitworth> AmeliaBR: at this point it's just an update and they've been surprised that it has normative impact
<fantasai> s/impact/impact on getComputedStyle/
<gregwhitworth> AmeliaBR: should we somehow extract that, and make it informative and then define gcs in some other way
<Rossen> q?
<dbaron> q+
<gregwhitworth> AmeliaBR: if it's a normative impact then we need to be strict terms that are clearly defined
<florian> q+
<Rossen> ack heycam
<gregwhitworth> heycam: I guess I am one of those people that applies to has normative impact, I always thought it was an informative information and prose would define it
<gregwhitworth> heycam: maybe I missed an earlier discussion
<krit> present: krit
<TabAtkins> https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height
<gregwhitworth> AmeliaBR: the summary, getComputedStyle for many props it doesn't return the computed style that gets inherited such as % or auto only pixel value
<TabAtkins> and the next instance of the phrase "applies to" as well
<gregwhitworth> AmeliaBR: that's where the applies to the normative impact
<gregwhitworth> heycam: does CSSOM point to applies to
<gregwhitworth> TabAtkins: yes
<gregwhitworth> TabAtkins: but none of us knew this - so maybe we fix that definition. None of our applies to are not written as though they're normative
<Rossen> ack dbaron
<krit> q+
<gregwhitworth> dbaron: I think the spec for getComputedStyle is not yet where impl should change to match the spec
<gregwhitworth> dbaron: maybe someone took a shortcut to point to applies to - but it's probably not an accurate definition
<gregwhitworth> AmeliaBR: I'm not asking impl to match the CSSOM spec it's about spec consistency
<gregwhitworth> AmeliaBR: but it's using a terminology that isn't explicitly defined elsewhere
<gregwhitworth> florian: also applies to it's not just a yes/no category - there has to be prose
<Rossen> ack florian
<gregwhitworth> florian: I'd be in favor in keeping applies to somewhat wishywashy
<gregwhitworth> florian: but also helping clarity for SVG is useful
<astearns> ack krit
<Rossen> ack krit
<chris> q?
<gregwhitworth> krit: besides that Applies TO we need to look at the prose, many text layout keep SVG in mind as well
<gregwhitworth> krit: if there is anything that the SVG specs can do to help that would be good to know as well
<gregwhitworth> krit: that would help interoperability between SVG/CSS very good as well
<gregwhitworth> AmeliaBR: that's very good feedback as well
<krit> ack krit
<gregwhitworth> AmeliaBR: I don't think we have them defined in one place, so we can improve that on our end
<gregwhitworth> AmeliaBR: so then it's kind of - the current specs it'll be a massive review and giant PR to make sure we do have clear defs for what applies to SVG and how
<gregwhitworth> florian: this will probably be more than a blue box change but a prose change
<florian> q+
<gregwhitworth> AmeliaBR: then moving forward, try to think about how it works on SVG, feel free to reach out. We've discussed content, contain, etc. but the questions need to be asked
<Rossen> ack florian
<gregwhitworth> florian: it's a process question, these categories can be aware of - are they different between SVG1.1 & 2?
<gregwhitworth> AmeliaBR: some of them have changed and some have been simplified
<gregwhitworth> AmeliaBR: I think there are a couple new categories
<chris> There are changes in SVG2, mostly simpfilfications.
<chris> q+
<gregwhitworth> florian: it would be unfortunate if no spec can get to rec until SVG 2 does
<gregwhitworth> florian: I don't want to gate everything on SVG getting to rec
<gregwhitworth> AmeliaBR: most will be in SVG 1.1 already but the SVG editors need to make sure those defs are in one place
<chris> q?
<gregwhitworth> AmeliaBR: that covers the main topic of this issue
<gregwhitworth> chris: The issue that florian raised is a quite large CSS one
<gregwhitworth> chris: whenever a spec goes to rec but it has these refs to EDs etc
<gregwhitworth> chris: we have a highly intertwined set of specs and it's really hard - and SVG doesn't really change this but adds
<gregwhitworth> florian: the problem is we have the bedrock of CSS2.1, at times it's more convenient to link to newer things because it has more things and it kind of makes it possible, but SVG is outside of that bedrock
<gregwhitworth> chris: there have been a few cases in SVG2 that are linking to SVG1.1, etc
<gregwhitworth> chris: as for CSS, I think it shouldn't be too large of a problem - there is a last resort
<krit> q+
<Rossen> ack chris
<gregwhitworth> florian: if it's a generic ref SVG then that's fine, but if we're starting to add 3 paragraphs prose about SVG that don't exist then you need to implement it and get that to rec and have a hard dependency.
<gregwhitworth> chris: we have some concepts for graphic elements and SVG1.1 has this stuff
<gregwhitworth> krit: just one comment
<gregwhitworth> krit: SVG2 categories are supposed to make things easier
<Rossen> ack krit
<gregwhitworth> krit: but if you would like to link to 1.1 that's fine for normative reference as long as it's defined what happens to the content in SVG we don't care if it's 1.1 or 2
<gregwhitworth> AmeliaBR: if there isn't something in there, then you can add some examples that says you don't have to implement and give branches
<gregwhitworth> florian: that spec that references it can't go to rec either because they're dependant on it
<gregwhitworth> krit: in those weird cases, sure link to 1.1 SVG
<gregwhitworth> krit: most of the issues are text related
<gregwhitworth> Rossen: ok, that sounds good
<gregwhitworth> AmeliaBR: we should open an issue into defining getComputedStyle further
<gregwhitworth> ACTION AmeliaBR : Open an issue to define getComputedStyle
<trackbot> Created ACTION-876 - : open an issue to define getcomputedstyle [on Amelia Bellamy-Royds - due 2019-03-05].
<gregwhitworth> s/liam/emilio
<AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3414

[frivoal]

See also https://github.com/w3c/csswg-drafts/issues/3412