-
Notifications
You must be signed in to change notification settings - Fork 132
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
Update getNumberOfChars() definition #200
Comments
Chrome and Safari do not seem to follow the current definition, I haven't checked the other user agents. |
Good catch, @jarek-foksa. We do need to distinguish between title/desc text and actual rendered text content. I'm less convinced whether a JS method like At this point, we can't rely on Also, if we do re-write this method in a way that reflects rendered text as currently styled, I would want to write it in a way that would be inclusive of CSS generated text (as discussed in #125). |
@AmeliaBR If the goal is to follow the existing implementations, then I would just make the spec state the only characters to be counted are those that have corresponding glyphs rendered on the screen. That would exclude any characters belonging to never-rendered elements ( |
Ok, so here's a test: Some findings:
|
From my testing on Chrome, Safari and Firefox, |
@jarek-foksa Yep, you're right. I fixed my test and updated my comment above. |
The spec reference to
Removing the
An algorithmic definition thereof would look something like:
However, since you need to compute CSS styles for That could be introduced into the recursive algorithm by either checking whether this element is rendered (and always returning 0 if it isn't), or by looking explicitly at the However, because there is a dependency on CSS, this algorithm would not be defined for an element that is currently detached from a document, unless we explicitly defined it to use the initial values of the properties. Also, on the question of E.g., for something like the following JSBin demo:
Chrome & Edge render it to match:
But Firefox renders it to match:
Assuming the Chrome/Edge behavior is deemed correct, so that _But_ the same behavior would also have to be used for all the other character-count methods. E.g., if That behavior, of only counting, positioning, and querying the final rendered text after CSS processing, is consistent with the approach to whitespace (which is or isn't included in the count, based on current collapsing rules) and keeps us open to allowing (Aside, this will get really fun when you throw a For backwards consistency (and consistency with existing implementations), text length must still be measured in UTF-16 code points, equivalent to String.length in JavaScript. Once ECMAScript support for proper counting of mutli-byte characters is stable, we'll probably want to introduce parallel versions of the SVG methods that use those new rules, and an attribute or property on the elements to switch how x/y/dx/dy/rotate are counted. |
General comment about character-by-character positioning attributes: The goal should be to have predictability. The Firefox rendering of the test case meets this goal. You don't want characters to be jumping around if you turn on/off the display of a tspan. The "addressable characters" is meant to describe white space that has been discarded. That could be made more clear in the definition. |
But that's exactly what happens in normal text layout. You remove some text, and the rest moves over to replace it. If you don't want the other characters to move, you should be using |
See also this demo of hacking support for conditional line breaks, which is broken in Firefox because x/y attributes on the un-rendered |
@AmeliaBR Your last example could be handled by disabling dx/dy attributes in un-rendered
This way you get predictability in setting the spacing between E & F without having to wrap them in a new |
This issue should be run by @heycam . |
I think the whitespace issue (the number of characters can change based on computed CSS style) makes "predictable" a bit of a lost cause. As mentioned previously, I also would like to keep the option open to have CSS-generated text for auto-numbering tick marks and so on, and I don't see how that's possible if coordinates are assigned to characters before applying CSS modifications. That said, my top concerns are that (1) all behavior is clearly defined and (2) attributes that are declared directly on a display-none element do not affect layout. |
@AmeliaBR Could you review those commits please? I'm not so familiar with the text chapter. |
Including some final edits with respect to issues #200 and #210, as well as general typo fixes, formatting, and clarification. Changes the definition and example of `shape-margin` to reflect the fact that this is a property of the excluded element, not the element from which the exclusion is subtracted. (attn @Tavmjong) Adds a note about ::before and ::after being possible in the future (see #125). Makes ::selection and :focus styles a requirement for interactive user agents, while leaving open how that is implemented. (Most web browsers use background color as part of a selection style, and we don't have a way of specifying background color on a span of text!) Not the full edit I'd like to have done, but hopefully caught most normative issues.
Thanks! |
Milestone achieved =) |
I did an end-to-end review of the chapter, found a couple other places which needed adjustments based on this decision, For the
I was going to suggest that you review & close, but it seems you've already got there! Now I just have to commit a fix for some markup errors I discovered when previewing this post... |
The current definition of getNumberOfChars() method is as follows:
This does not look right to me. The
textContent
includes characters inside never-rendered elements such as<title>
and<desc>
or<tspan style="display: none">
. Those characters should not be counted.I would first spec
SVGElement.innerText
in a similar fashion to HTMLElement.innerText and then I would update the definition ofgetNumberOfChars()
to rely oninnerText
rather thantextContent
.The text was updated successfully, but these errors were encountered: