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.

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

Remove section on private use area in html #1751

Merged
merged 3 commits into from Jul 9, 2021
Merged

Remove section on private use area in html #1751

merged 3 commits into from Jul 9, 2021

Conversation

mattgarrish
Copy link
Member

@mattgarrish mattgarrish commented Jul 5, 2021

Removes the requirement to embed a font when using private use area code points as discussed in #1732.

We should wait on merging this to get an ok from the WG first, though, as it is a substantive removal.


Preview | Diff

@murata2makoto
Copy link
Contributor

Character Model for the World Wide Web: String Matching is already an informative reference, but Character Model for the World Wide Web 1.0: Fundamentals is not. But it has a subsection for private use code points. I think that it should be added as a reference.

@mattgarrish
Copy link
Member Author

What if instead of deleting the section entirely, we move it into the "discouraged constructs" section where it would be informative guidance? We could also generalize the prose so it's not so much about embedding a font as a brief description of the problems with private use area code points.

We could then point to charmod without explicitly disallowing, and also not have to get into overlapping accessibility requirements with WCAG in the accessibility techniques document.

@iherman
Copy link
Member

iherman commented Jul 6, 2021

EPUB 3 content document relies on HTML5, which does refer to the charmod document. Which is good. I do not think adding anything to the EPUB 3 spec adds anything that would not be equally valid for HTML: HTML authors are also expected to make sure that the fonts that are used match the Unicode characters they use, whether private or not.

My vote is to merge the PR as is.

@mattgarrish
Copy link
Member Author

HTML authors are also expected to make sure that the fonts that are used match the Unicode characters they use, whether private or not.

The only thing that worries me about EPUB is there's greater unreliability, and configurability, in reading systems than browsers. There's less assurance that an embedded font will be supported and more likelihood that users can change the default font, both of which lead to the wrong visual display (putting aside the accessibility issues).

But I agree this isn't a unique problem for EPUB, either generally or for accessibility, so can go either way.

Let's see what the group has to say on this.

@iherman
Copy link
Member

iherman commented Jul 9, 2021

The issue was discussed in a meeting on 2021-07-08

List of resolutions:

View the transcript

2. Private use areas in HTML

See github pull request #1751.

See github issue #1732.

Dave Cramer: we had a section in spec that said if you use unicode private use area (PUA) characters, then you should embed a font
… just having that statement in there seemed kind of odd. Its just best practice advice, and don't want to mess with unicode PUA
… PR would remove this section of spec
… mgarrish was waiting for confirmation from WG this was okay

Murata Makoto: is the proposal to entirely remove that section, and nothing else?

Wendy Reid: yes, and adding that to the change log

Brady Duga: there was also a comment on issue of moving it to discouraged constructs

Murata Makoto: in spec we refer to CHARMOD matching, but not CHARMOD fundamentals. I think we should refer to Fundamentals, too, fundamentals has a section dealing with PUA codepoints
… we should try to rely on these instead of inventing our own. Don't want to do anything that goes against what is already in Fundamentals

Murata Makoto: https://html.spec.whatwg.org/multipage/references.html#references

Wendy Reid: Ivan made the point that we rely on HTML5, which already refers to CHARMOD documents

Dave Cramer: to my mind this is an HTML question, and HTML refers to CHARMOD, so I don't see need for us to explicitly refer as well

Murata Makoto: does SVG refer to CHARMOD too?

Brady Duga: whether or not SVG does seems like a minor thing. It already encompases so much more, e.g. allowing authors to draw whatever characters they want

Matthew Chan: shiestyle addresses JP members in Japanese

Shinya Takami (高見真也): MURATA's opinion is not an objection to this proposal

Murata Makoto: yes, just suggesting a minor change

Dave Cramer: propose we accept this PR. If we have big problems with SVGs and PUA, then we can revisit

Proposed resolution: Merge PR 1751 (Wendy Reid)

Dave Cramer: +1

Murata Makoto: +11

Shinya Takami (高見真也): +1

Brady Duga: +1

Toshiaki Koike: +1

Matthew Chan: +1

Masakazu Kitahara: +1

Wendy Reid: +1

Ben Schroeter: +1

Resolution #2: Merge PR 1751

@iherman iherman merged commit 965846c into main Jul 9, 2021
@mattgarrish mattgarrish deleted the fix/issue-1732 branch August 19, 2021 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants