- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Feb 2019 18:42:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS properties should apply to some SVG properties as well`. <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> Topic: CSS properties should apply to some SVG properties as well<br> <gregwhitworth> AmeliaBR: I don't have a whole lot to update<br> <gregwhitworth> AmeliaBR: in comparison to the telecon<br> <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<br> <gregwhitworth> AmeliaBR: having to update the spec to say, "hey this also works" - some specs do this but it's not at all consistent<br> <gregwhitworth> AmeliaBR: the applies to in the definition is loosely defined<br> <Rossen> q?<br> <chris> rrsagent, here<br> <RRSAgent> See https://www.w3.org/2019/02/26-css-irc#T18-16-08<br> <gregwhitworth> AmeliaBR: when you look at CSSOM for getCOmputedStyle it has nromative impacts on whether you return the computed or used style<br> <gregwhitworth> AmeliaBR: I think this issue got added to the F2F that I would come with a pretty proposal but that hasn't happened<br> <gregwhitworth> AmeliaBR: In general I'd like to suggest that the applies to more rigorously defined which categories are used?<br> <heycam> q+<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <heycam> q+<br> <gregwhitworth> AmeliaBR: as far as how it works on SVG side is, it shows all elements but is it ALL elements considering SVG?<br> <gregwhitworth> AmeliaBR: instead of using the term elements we can use rendering tree terminology, etc<br> <gregwhitworth> AmeliaBR: also others mix elements and rendering tree words it's very incosistent<br> <gregwhitworth> AmeliaBR: the SVG element the same element in different layout contexts may or may not have a CSS box<br> <gregwhitworth> AmeliaBR: another thing for SVG - text content elements many text related props will apply to SVG Text but not all<br> <gregwhitworth> AmeliaBR: because the actual text layout is different<br> <gregwhitworth> AmeliaBR: it would be valuable to not have to re-analyze if it impacts SVG text, etc<br> <gregwhitworth> fantasai: what are we trying to conclude<br> <gregwhitworth> AmeliaBR: at this point it's just an update and they've been surprised that it has normative impact<br> <fantasai> s/impact/impact on getComputedStyle/<br> <gregwhitworth> AmeliaBR: should we somehow extract that, and make it informative and then define gcs in some other way<br> <Rossen> q?<br> <dbaron> q+<br> <gregwhitworth> AmeliaBR: if it's a normative impact then we need to be strict terms that are clearly defined<br> <florian> q+<br> <Rossen> ack heycam<br> <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<br> <gregwhitworth> heycam: maybe I missed an earlier discussion<br> <krit> present: krit<br> <TabAtkins> https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height<br> <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<br> <TabAtkins> and the next instance of the phrase "applies to" as well<br> <gregwhitworth> AmeliaBR: that's where the applies to the normative impact<br> <gregwhitworth> heycam: does CSSOM point to applies to<br> <gregwhitworth> TabAtkins: yes<br> <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<br> <Rossen> ack dbaron<br> <krit> q+<br> <gregwhitworth> dbaron: I think the spec for getComputedStyle is not yet where impl should change to match the spec<br> <gregwhitworth> dbaron: maybe someone took a shortcut to point to applies to - but it's probably not an accurate definition<br> <gregwhitworth> AmeliaBR: I'm not asking impl to match the CSSOM spec it's about spec consistency<br> <gregwhitworth> AmeliaBR: but it's using a terminology that isn't explicitly defined elsewhere<br> <gregwhitworth> florian: also applies to it's not just a yes/no category - there has to be prose<br> <Rossen> ack florian<br> <gregwhitworth> florian: I'd be in favor in keeping applies to somewhat wishywashy<br> <gregwhitworth> florian: but also helping clarity for SVG is useful<br> <astearns> ack krit<br> <Rossen> ack krit<br> <chris> q?<br> <gregwhitworth> krit: besides that Applies TO we need to look at the prose, many text layout keep SVG in mind as well<br> <gregwhitworth> krit: if there is anything that the SVG specs can do to help that would be good to know as well<br> <gregwhitworth> krit: that would help interoperability between SVG/CSS very good as well<br> <gregwhitworth> AmeliaBR: that's very good feedback as well<br> <krit> ack krit<br> <gregwhitworth> AmeliaBR: I don't think we have them defined in one place, so we can improve that on our end<br> <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<br> <gregwhitworth> florian: this will probably be more than a blue box change but a prose change<br> <florian> q+<br> <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<br> <Rossen> ack florian<br> <gregwhitworth> florian: it's a process question, these categories can be aware of - are they different between SVG1.1 & 2?<br> <gregwhitworth> AmeliaBR: some of them have changed and some have been simplified<br> <gregwhitworth> AmeliaBR: I think there are a couple new categories<br> <chris> There are changes in SVG2, mostly simpfilfications.<br> <chris> q+<br> <gregwhitworth> florian: it would be unfortunate if no spec can get to rec until SVG 2 does<br> <gregwhitworth> florian: I don't want to gate everything on SVG getting to rec<br> <gregwhitworth> AmeliaBR: most will be in SVG 1.1 already but the SVG editors need to make sure those defs are in one place<br> <chris> q?<br> <gregwhitworth> AmeliaBR: that covers the main topic of this issue<br> <gregwhitworth> chris: The issue that florian raised is a quite large CSS one<br> <gregwhitworth> chris: whenever a spec goes to rec but it has these refs to EDs etc<br> <gregwhitworth> chris: we have a highly intertwined set of specs and it's really hard - and SVG doesn't really change this but adds<br> <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<br> <gregwhitworth> chris: there have been a few cases in SVG2 that are linking to SVG1.1, etc<br> <gregwhitworth> chris: as for CSS, I think it shouldn't be too large of a problem - there is a last resort<br> <krit> q+<br> <Rossen> ack chris<br> <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.<br> <gregwhitworth> chris: we have some concepts for graphic elements and SVG1.1 has this stuff<br> <gregwhitworth> krit: just one comment<br> <gregwhitworth> krit: SVG2 categories are supposed to make things easier<br> <Rossen> ack krit<br> <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<br> <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<br> <gregwhitworth> florian: that spec that references it can't go to rec either because they're dependant on it<br> <gregwhitworth> krit: in those weird cases, sure link to 1.1 SVG<br> <gregwhitworth> krit: most of the issues are text related<br> <gregwhitworth> Rossen: ok, that sounds good<br> <gregwhitworth> AmeliaBR: we should open an issue into defining getComputedStyle further<br> <gregwhitworth> ACTION AmeliaBR : Open an issue to define getComputedStyle<br> <trackbot> Created ACTION-876 - : open an issue to define getcomputedstyle [on Amelia Bellamy-Royds - due 2019-03-05].<br> <gregwhitworth> s/liam/emilio<br> <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3414<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3414#issuecomment-467560883 using your GitHub account
Received on Tuesday, 26 February 2019 18:42:04 UTC