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-display] textPath and SVG unboxing for display:contents #2118

Closed
lilles opened this Issue Dec 18, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@lilles

lilles commented Dec 18, 2017

When implementing [1] in Blink, the following came up as a question during code review:

fs@opera.com: "I find it a bit odd that <tspan> gets this treatment, but not <textpath>, since they are both "inline level" text content elements - that's a spec issue though..."

@tabatkins

[1] https://drafts.csswg.org/css-display/#unbox-svg

@fantasai

This comment has been minimized.

Contributor

fantasai commented Jan 11, 2018

I'm guessing it's a specification error, then. Probably should have made that a non-exhaustive list.

@tabatkins

This comment has been minimized.

Member

tabatkins commented Jan 18, 2018

No, it's meant to be exhaustive, I just didn't realize that textPath existed. It should indeed be treated the same as tspan

@tabatkins

This comment has been minimized.

Member

tabatkins commented Jan 19, 2018

All right, fixed in 1432231. I reviewed the Element Index in SVG2 and also added a and "unknown elements" (which are defined to render like g) to the list, along with an note explaining the reasoning for the groups.

@tabatkins tabatkins closed this Jan 19, 2018

@fantasai fantasai added the Agenda+ label Mar 20, 2018

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 20, 2018

I'd prefer if we didn't put exhaustive lists of non-CSS constructs in our CSS specs. It's fine to be comprehensive if we can, but our lists should be written as being open-ended so that changes in the external technology don't automatically create errors in our specs.

@fantasai fantasai reopened this Mar 20, 2018

@AmeliaBR AmeliaBR added the SVG label Mar 21, 2018

@AmeliaBR

This comment has been minimized.

AmeliaBR commented Mar 21, 2018

Would it be better to link to SVG element-category definitions?

  • Root <{svg}> would be "an <svg> element with CSS box layout" (in fact, I'd strongly argue against using the word "root" if you want this behavior to apply to <svg> that is a child of an HTML element, and is therefore not the root of its document.)

    ''display: contents'' behaves as ''display: none''.

  • <{tspan}>, <{textPath}> would be text content child elements.

    Nested <{svg}>, <{a}>, <{g}>, and unknown elements would be all other SVG container elements that are also renderable elements.

    Only <{use}> (treated as a Shadow DOM container) would need to be called out separately

    ''display: contents'' strips the element from the formatting tree,
    and hoists its contents up to display in its place.

  • any other SVG elements

    ''display: contents'' behaves as ''display: none''.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 21, 2018

@AmeliaBR Yes, I think that would be much better. Would you mind drawing up a pull request (or just committing against this issue number if you prefer)?

@AmeliaBR

This comment has been minimized.

AmeliaBR commented Mar 22, 2018

@fantasai, I'll try to get that for next week.


For anyone else reviewing this issue, there's some relevant background in #540

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Mar 26, 2018

The SVG Working Group just discussed [css-display] textPath and SVG unboxing for display:contents.

The full IRC log of that discussion <AmeliaBR> Topic: [css-display] textPath and SVG unboxing for display:contents
<AmeliaBR> GitHub: https://github.com//issues/2118
<AmeliaBR> Proposed change: https://github.com//issues/2118#issuecomment-374802030
<BogdanBrinza> Resolution: No objection from the working group to the wording Amelia used in the proposed change for CSS display: contents
@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Apr 4, 2018

The Working Group just discussed 'display: contents' on SVG elements, and agreed to the following resolutions:

  • RESOLVED: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes.
The full IRC log of that discussion <dael_> Topic: 'display: contents' on SVG elements
<dael_> github: https://github.com//issues/2118
<dael_> TabAtkins: We've resolved on which SVG elements respond in which ways to display contents.
<dael_> TabAtkins: It was pointed out I made a mistake. That points to a larger issue that as SVG evolves the elements that are categorieze will evolve. Instead of cat explicitly we should use the element categories that SVG defines.
<dael_> TabAtkins: AmeliaBR suggested a particular grouping for each one. SVG WG did review and said tiw as fine. I think it's fine. If the rest of the group is okay switching to using SVG categories we can do that.
<dael_> ChrisL: I agree this is best and I like AmeliaBR categories
<dael_> AmeliaBR: Categories are appropriate. They weren't made with this use case, but by intersecting existing categories we can make it work.
<dael_> AmeliaBR: One thing, we haven't designed...would dsiplay:contents on a text-path override layout defined on an attribute?/
<dael_> AmeliaBR: t-span and text-path are ones we're saying text content works as an unboxing. They both involve layout with attributes not CSS properties. I had been assuming that a display:contents would mean ignore any layout specific to this element, but we should be explicit
<dael_> ChrisL: Agree.
<dael_> ChrisL: They're not presentation attributes?
<dael_> AmeliaBR: No.
<dael_> TabAtkins: I need to finally write up the explination for how SVG rendered into CSS box model. WE need to do this tap dance and we know ituses a reasonable concept of boxes. Then it'll all work out.
<fantasai> s/need to do/keep having to do/
<dael_> AmeliaBR: Can you do that by next week? ^-^ Elsewise a note saying it unboxes all layout regardless of syntax.
<dael_> florian: Follow up question on attributes. These presentational attributes on the element, can some be ddesc as inheriting to anon box witht he text? Or are they all clearly to the surpressed box?
<dael_> AmeliaBR: Good and complex question
<dael_> TabAtkins: There's no anon box around text, it's lifted to parent. ANything presentational that's CSS disappears. Anything which is just in SVG terms we'll for now put somethin in that says do the same.
<dael_> florian: So they just disappear? You bold a font in the style and display:contents on the span you get bold text. Do we have things like that in SVG where they need to apply to the text run?
<dael_> AmeliaBR: The bit where I said it was complex...the layout attributes inherit down in a way that doesn't quite match CSS because it's per character. But it's similar to inheritence.
<dael_> florian: It seems to me the thing we're about to resolve on it right but a bit incomplete. We need to talk per attribute. Or is there a well engouh defined thing in SVG.
<dael_> AmeliaBR: What's the spec status? Trying to get to CR and don't want an open issue?
<dael_> TabAtkins: It's not a big issue. We look at each and say if it's an inheriting property.
<dael_> fantasai: Next step is WD so it doesn't need fix today.
<dael_> AmeliaBR: I can try and write up something and perhaps a note about an open issue needing more review.
<dael_> fantasai: Sounds like we're going to accepth the changes. There is a followup issue on attributes that should be opened separately.
<dael_> astearns: Question on the categories. We're going to call out categoires that are not doing display:none and anything not called out is the display:none. If at some point SVG defines new things that might have something different then display:none we'll have to add it in the future. Is that the right approach?
<dael_> AmeliaBR: Yeah. Presumably most elements that are new would fit into one of these categories. This idea with these category names is they should be open ended.
<dael_> astearns: So a new thing would be classified as a renderable element it would be fixed.
<dael_> AmeliaBR: If we defined a new attribute as a renderable element it would auto-apply
<dael_> ChrisL: It would only be a problem if we needed a new category
<dael_> astearns: Prop: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes
<florian> AmeliaBR, do you want to file that new issue? I believe you got my point, and you're more likely than me to phrase it right.
<dael_> astearns: Obj?
<dael_> RESOLVED: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes.
@AmeliaBR

This comment has been minimized.

AmeliaBR commented Apr 9, 2018

@fantasai

I've pushed edits to a new branch. Three commits: the first one to address this issue, and then two for #2502 (new text and an inline issue pointing back to GitHub).

I haven't worked with Bikeshed before, and don't have a build system set up locally, so I'm not sure I've got the linking syntax correct. Please review that (& the text) and correct or merge if OK.

@tabatkins tabatkins closed this in 2cdf747 Apr 20, 2018

fergald added a commit to fergald/csswg-drafts that referenced this issue May 7, 2018

Display contents svg (w3c#2599)
* [css-display] Describe SVG unboxing with element categories

Fixes w3c#2118

* [css-display] Clarify impact of display: contents on SVG attributes

Addresses w3c#2502

* [css-display] Add an issue re SVG attributes & display: contents
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment