Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-display] textPath and SVG unboxing for display:contents #2118

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

[css-display] textPath and SVG unboxing for display:contents #2118

lilles opened this issue Dec 18, 2017 · 10 comments
Assignees
@AmeliaBR
Labels
css-display-3 Current Work SVG Tracked in DoC

Comments

@lilles
Copy link
Member

lilles commented Dec 18, 2017 •
edited
Loading

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

[email protected]: "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
Copy link
Collaborator

fantasai commented Jan 11, 2018 •
edited
Loading

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

@fantasai fantasai added the css-display-3 Current Work label Jan 11, 2018
@tabatkins
Copy link
Member

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
Copy link
Member

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.

@fantasai
Copy link
Collaborator

fantasai commented Mar 20, 2018 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link
Contributor

@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
Copy link
Member

css-meeting-bot commented Mar 26, 2018 •
edited by fantasai
Loading

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

@astearns astearns mentioned this issue Mar 26, 2018
Closed
@css-meeting-bot
Copy link
Member

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 AmeliaBR mentioned this issue Apr 5, 2018
Closed
@AmeliaBR AmeliaBR self-assigned this Apr 9, 2018
@AmeliaBR AmeliaBR mentioned this issue Apr 9, 2018
Open
AmeliaBR added a commit that referenced this issue Apr 9, 2018
@AmeliaBR
[css-display] Describe SVG unboxing with element categories
685ed46 
Fixes #2118
@AmeliaBR
Copy link
Contributor

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.

fergald pushed a commit to fergald/csswg-drafts that referenced this issue May 7, 2018
@tabatkins @fergald
Display contents svg (w3c#2599)
7539b4b 
* [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
@heycam heycam mentioned this issue Nov 8, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AmeliaBR AmeliaBR

Labels
css-display-3 Current Work SVG Tracked in DoC
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tabatkins @fantasai @lilles @AmeliaBR @css-meeting-bot