WP affords personalization

[TzviyaSiegman]

2.1.11 Personalization
The user must have the possibility to personalize his or her reading experience.

Picking up on #52

[TzviyaSiegman]

See work done by @JayPanoz and Readium at https://github.com/readium/readium-css/issues

[JayPanoz]

If that can help, here are the pointers to the related docs (and a link to the discussion when applicable):

1. The classification we’ve been using to handle user overrides;
2. Recs to manage user settings, given the current state of personalization + discussion which I can re-open if needed;
3. The list of settings we implemented, for which you can ignore the technical details (+ i18n is discussed in this context);
4. Baseline for a11y-related user settings + its discussion, which is still open + default fonts for dyslexia;
5. E-production feedback and requests since some authors expectations/requests/etc. may impact this discussion – we couldn’t find a perfect balance, given the current technical limitations we have to deal with but it provided very useful insights to design the whole.

Hope that helps, do not hesitate to cc me for clarifications/further details.

[HadrienGardeur]

We also have something in our current draft about this: https://w3c.github.io/wpub/#aff-user-settings

[JayPanoz]

Further details.

The main issue really is the following:

To provide user settings in their reader mode, browsers usually get rid of most of the author styles. There's always a tension in reading environments between author styles and the user's preference, which is very hard to balance.

CSS is getting more and more complex, and we don’t have a proper mechanism to deal with that. On top of that, it’s liberal by nature and it becomes increasingly complex to apply some user settings depending on the publication.

I’ve been monitoring Personalization Semantics since we have a list of specs impacting the Readium CSS project in the longer term, but it looks like this type of personalization has been removed from what was formerly COGA Semantics.

Problem is we had to find ways to make personalization work even for simple settings like font size.

So in this context, it’s quite understandable reader modes strip all styles. It’s just that ebooks have been ahead the whole time, and we tried to find solutions to keep authors’ styles. But I’m not optimistic this is sustainable AS-IS, since in the absence of dedicated specs, a lot of our resolutions can be considered CSS tricks – which are bound to fail in some conditions.

[edit] That also explains why reader modes are using heuristics right now, and will simply make themselves unavailable if they deem the page unmanageable for various reasons e.g. non-semantic webpage.

[avneeshsingh]

Personalization is quite a wide topic in W3C. I think that we should only focus on what personalizations are specific to WP, which cannot be addressed by personalizations provided by HTML, CSS etc.

[jmulliken]

Are there specific personalization options that we can identify as unique to WP? Is it enough to say that the same personalization options available in a browser should be available for WP? Does that even need to be said if that's the case? Or are there specific options we could list out?

[iherman]

I would love to get back to the possibility to use alternative CSS files. I agree with @JayPanoz that CSS has become extremely complex, and end-users may not be in position to comprehend the CSS that is used for a specific document. But if, at least, it would be possible for the author of a WP to provide alternate CSS files (e.g., by providing alternate colours or fonts, like the popular changes to "night mode") and we could somehow say that RS-s should (re-)introduce the feature of the users making a change among alternative CSS files, we would be in a better place.

Alas, most (all?) browsers have stopped this. There is an example on MDN:

https://developer.mozilla.org/samples/cssref/altstyles/index.html

it works in Firefox, but is ignored in Safari or Chrome...

[avneeshsingh]

Alternate CSS can be helpful in addressing personalization as well as accessibility needs (used both termms although the dividing line between these two is quite thin).
Are there any major issues in using alternate CSS that we are not aware of?

[JayPanoz]

Are there any major issues in using alternate CSS that we are not aware of?

Never had time to do some research but it would be interesting to check if they were not implemented/removed due to low usage or if there were implementation issues.

[iherman]

I think it was mostly usage. That was made even more difficult by the fact that today's CSS files can be extremely complex and generated by tools, and it can be fairly difficult to produce alternate sheets...

[JayPanoz]

And authors now have CSS custom properties to do theming/alternate styles so that’s also something to take into account as it will undoubtedly be mentioned as an alternative to alternate stylesheets.

[JayPanoz]

+ CSS Environment Variables Module Level 1 is being currently drafted, i.e. CSS custom properties but for the UA (or authors’ global props which don’t cascade).

They’re currently meant to be usable in media queries so one could imagine leveraging that in the future to expose reading modes, etc.

[avneeshsingh]

Indeed, use of media queries has good potential. Both CSS custom properties and CSS Environment Variables Module are also applicable on websites, so what specific enhancement is required for WP.

[diagram-codesprint]

I have been looking at this and trying to determine if it should be closed or if we do need an affordance. Here are my thoughts looking for others feedback.
It sounds like CSS Environment variables with Media Queries or CSS custom properties might give us all the Personalization affordances we need? I guess the argument is that there is nothing specific to a Web publication that is different than HTML itself in terms of personalization affordances.

I am just wondering if we don’t put anything in couldn’t this mean that an author could create an EPUB that couldn’t be personalized? For example if one hard coded the font size and color in the content directly.

[clapierre]

Sorry, was logged in with my alter-ego above.
Charles

[iherman]

@clapierre We do have an issue nevertheless : as far as I can see, all those solutions are single document centric. Eg:

This specification defines the concept of environment variables and the env() function, which work similarly to custom properties and the var() function, but are defined globally for a document.

(from https://drafts.csswg.org/css-env-1). So an affordance for setting all these publication-wide is still something we should document.

Also, again as far as I can see, many of these things happen authoring time. Nothing is said how, fir example, the personalization semantics translate into user interaction. There again, all user interaction should be for the whole publication.

So yes, I believe having this documented in our spec would be good...

[llemeurfr]

Authoring publications is already complex, and I can hardly imagine authors providing alternate stylesheets along with their publications.

Personalization is a user action on UAs (reading apps), to select a font, font size, background color etc. that fits his needs. This is even more important for dys* people, who need to personalize line spacing, line highlights etc.

The issue, as highlightened by @JayPanoz, is that the author's CSS can easily clash with the UA personalization CSS (which is made flexible via CSS custom properties).

Therefore either we try to restrict in the spec what the author can do in its author's CSS (so that developers of UA CSS's can be confident that they will avoid a clash), or we just express in best practices what a good relationship between the author's and the UA CSS should be.

Both are difficult (and I think the former is impossible).

[JayPanoz]

Right, the clash really is inevitable right now.

On the web for instance, either authors “collaborate” using media queries, environment variables, etc. and give hints the UA can use, or the UA will override their styles anyway, and sometimes it goes extremely wrong.

A recent example is Dark Mode, which will be coming in the next MacOS: a discussion is happening right now in the CSSWG to make that a media query.

Some authors will do that as soon as those features are implemented, some others won’t – for various reasons, not judging them obviously, not least because it’s super difficult to keep track of every CSS module created/implemented.

A note though, Chrome removed user stylesheets and deemed such a feature should be an extension like 4–5 years ago. You now have multiple extensions available. To name a few:

• Stylish (warning: see update below)
• Styler
• User CSS
• Stylebot

The most popular being by very far Stylish, also because users can share their stylesheets and knowing how to CSS is therefore not necessary.

It shouldn’t come as a surprise dys features are available in the form of an extension as well e.g. DysAide.

Then, currently, when user prefs are directly available in the browser UI, chances are you’re in Reader Mode. And to repeat myself:

reader modes strip all styles.

So

For example if one hard coded the font size and color in the content directly.

We already have a lot of those ones to deal with. Their amount is significant enough to implement some user settings in the most brutal way possible, to make sure they will behave as expected. To be honest, in such instances, stripping all styles, à la reader mode, wouldn’t do a disservice to both the user and the author – yeah, it was really that bad.

Update: removed Stylish link because you may not want to install it, given it’s now stealing all your internet history.

[avneeshsingh]

It would be good to have a note for personalizations that applies to whole publications. At the same time there is usecase for overriding it. In first html file, font may be uniformily Ariel 11. But on second html page, there are quotes within intalics in pt 10 font size. This would create problem for a low vision person, who may like to increase font size of second page only. So, personalization should work at page level also along with global level.

Another question, how websites implement personalization such that when font is increased by the user on the first page, it also increases on other pages that the user visits.

[JayPanoz]

Another question, how websites implement personalization such that when font is increased by the user on the first page, it also increases on other pages that the user visits.

If the implementation is done by the author, it’s domain-specific and the setting will be stored somewhere (e.g. cookie, localStorage, etc.) using JavaScript, in order to get retrieved when the user comes back. Here’s a basic demo.

Private browsing may defeat this mechanism though e.g. on iOS, you can’t set and get localStorage values in Private Browsing mode.

[avneeshsingh]

Thanks @JayPanoz for clarifying that website use the usual stuff like cookies.
So, by global application of personalization to WP, are we intending to standardize the way of doing it in WP? Is some other group in W3C like personalization TF trying to standardize it for websites? Charles?

[clapierre]

The personalization TF is coming up with a vocabulary of properties and values to annotate content to add additional semantic information.
Here is our editors draft of Personalization Semantic Content one of the modules we are working on which provides a vocabulary of terms that can be used to enhance content with information about controls, symbols, and user interface elements, etc. User agents use these semantics to augment or adapt content. This helps the user use and understand the content, and supports simplification and management of distractions.

Although this can be applied to a WP, I believe this would only apply to a very small subset of WP's that would be embedding advance inter-actives and controls that would need to be semantically marked up.

That being said it, some authors may want to semantically mark up their books to allow a simplified version or alternate representation using symbols.

[bduga]

I realize the conversation has diverged from this point, but I want to circle back to alternative style sheets. Aside from the various issues mentioned (complexity, lack of implementation) this brings us back to who is writing the reading system or if one exists at all. Providing style sheets for implementations of night mode puts the UI burden on the publisher, which means every book I read will have different personalization options depending on who published them. There is no way for me to pick the software that has the features I want, since the actual implementation (or lack of implementation) is left to the publisher. Even if this was a good idea, I see no reason to go back to alternative style sheets when a publisher could just include a menu to modify the style of the book. It is also difficult (impossible?) to implement night mode with just CSS. Blue shift nightmode features have popped up recently that require time-based color changes which can't be done with CSS. Alternative style sheets were in the epub spec specifically for night mode and were never used, in part because even when we released the spec they weren't powerful enough.

…

On Wed, Apr 25, 2018 at 9:44 PM Ivan Herman ***@***.***> wrote: I would love to get back to the possibility to use alternative CSS files. I agree with @JayPanoz <https://github.com/JayPanoz> that CSS has become extremely complex, and end-users may not be in position to comprehend the CSS that is used for a specific document. But if, at least, it would be possible for the author of a WP to provide alternate CSS files (e.g., by providing alternate colours or fonts, like the popular changes to "night mode") and we could somehow say that RS-s should (re-)introduce the feature of the users making a change among alternative CSS files, we would be in a better place. Alas, most (all?) browsers have stopped this. There is an example on MDN: https://developer.mozilla.org/samples/cssref/altstyles/index.html it works in Firefox, but is ignored in Safari or Chrome... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#138 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADXPZCUnu1Dxu6YtKlY6UdiBtwk6zuOBks5tsVCTgaJpZM4SD7tI> .

[lseeman]

1. This needs to be harmonized with the personalization work such as the work in the help module for alternative content.
   see the use cases in module 1: https://rawgit.com/w3c/personalization-semantics/ such as simlification
   and use cases in module 2: https://rawgit.com/w3c/personalization-semantics/master/help/index.html

2. Also I think navlists / alternative navigation should be able to go via any different types of content or call out box. For example, you may have call out boxes of likeywords. A user with a reading disability or ADD may prefer to study by navigating through each keyword call out box. where s/he does not know one of there terms they need to read on possibly jumping to the explanation of the term. When they do know the terms they can simply navigate to the next callout box o f keyword terms. In other words navlist should be easy to generate by the user for any content type, or reg ex/ xpath etc - including from an extended vocabulary. This would also allow a user to navigate though annotations by a particular user or a combination of criteria such as annotations made by my teacher to either everyone or me specifically.

[JayPanoz]

Blue shift nightmode features have popped up recently that require time-based color changes which can't be done with CSS.

Naïve question: should “Night Shift” modes be considered Night Mode? The way they work is indeed not necessarily the same i.e. global filter versus inverted colors (which can be either a global filter or something else).

That being said, “night mode” is a loose concept in practice nowadays so “can't be done with CSS” already applies.

[JayPanoz]

Just to make it explicit, I updated one of my previous messages due to privacy concerns: it indeed looks like the Stylish extension is stealing all your internet history so don’t install it. Sorry about that.

[deborahgu]

FWIW, @JayPanoz , Stylus is Stylish but private. As they say,

Unlike other similar extensions, we don't find you to be all that interesting. Your questionable browsing history should remain between you and the NSA. Stylus collects nothing. Period.

[clapierre]

WP affords the ability to personalize the content of the publication.

Short description

A Web Publication affords the ability that a User Agent (UA) / Reading System (RS) can personalize or customize the content of the publication to meet the user’s needs.

Expression

Consider the work being done in the Personalization TF (soon to be under APA). We should follow what is being done especial in regards to “Personalization Semantics Content Module 1.0” as outlined in the "Personalization Semantics Explainer 1.0".
Two other modules, currently editors drafts, which will also be important for personalization of WP are the “Personalization Help and Support 1.0" and “Personalization Tools 1.0”

Use Cases

A user may require a specific font type/family to be applied to the entire publication including all text within, TOC, footnotes, references, etc., as well as the ability to adjust the justification, font size, font color, background color, character, word, line spacing and margins. A WP must afford the customization of all properties of the textual content within.

Below are a few examples of which personalization affordances need to be considered. Please note that this is not an exhaustive list.

A low vision user may want to follow the AFB’s Best Practices and Guidelines for Large Print Documents used by the Low Vision.

Simplification: Based on a user’s settings, a less complex rendition of the WP could be shown.

Adding Context: If a user agent or script knows the context of links, buttons, and other page elements then symbols and text which a user better understands may be used.

Interoperable Symbols: Those with complex communication needs using Alternative and Augmentative Communication (AAC) systems. User needs, for example, I need symbols that help me understand content.

I need contextually-relevant graphs and pictures to supplement text so I can understand a point without a lot of reading.

More Help: Some users may need additional information, , specifically additional help information or context specific help. There should be additional attributes which allow an author to indicate the existence of additional information.

Literal: provides alternative text for people who prefer content that does not use non-literal text, such as metaphors.

Number Free: Numerical concepts could be rendered by the user agent in a slightly different way so that the user is aware that a number free explanation is available. The user can then mouse over the content and a mechanism, for example, tooltips would give the number free value.

Step Indicator: As an example, given an interactive book which includes a quiz at the end of each chapter. The user must be able to track all completed tasks in a sequence of tasks so they know where they are in the process and can be reminded of the tasks that are complete or has yet to be completed. In addition, the user must be able to navigate to any completed task in order to make corrections.

Examples

Example of the manifest/infoset terms containing this affordances expression

Testing

UA/RS’s may support this feature buy adjusting the justification, font properties, and spacing (character, word, and line). Note increasing the font size, line spacing, or margin width should still result in being able to for example get to the same page as someone who has a smaller font size and different page layout.

[iherman]

@clapierre I have two problems with the WAI work:

1. It is very preliminary. This means that it would be very difficult to incorporate any result of it in our document
2. If my understanding is correct (please correct me if I am wrong) it is concerned about putting some ARIA-like personalization points into the document. Ie, it is author centric. This is clearly important, but some of the personalization issues we may have (eg, change the font globally) is really a user-centric action, and the authors do not really have a say in it...

[avneeshsingh]

The good work of personalization task force will be available to the web in general, including WP/PWP. I think that the only thing that we may like to highlight is that WP should enable personalization of complete WP as a whole and should also enable further personalization of individual resources.

[laudrain]

@clapierre When reading the use cases:

A user may require a specific font type/family to be applied to the entire publication including all text within, TOC, footnotes, references, etc., as well as the ability to adjust the justification, font size, font color, background color, character, word, line spacing and margins. A WP must afford the customization of all properties of the textual content within.

I see functions belonging to the UA not the WP itself.
On that subject we could see the tremendous work done by Jiminy Panoz for EDRLab in Readium-CSS

[JayPanoz]

Maybe one additional observation…

(sorry I’ve lost track of this issue yesterday for some reason and am now struggling to understand the expected outcome unless it is “WP should enable personalization of complete WP as a whole and should also enable further personalization of individual resources”, as @avneeshsingh said above.)

Shouldn’t night modes media queries, environment variables, and an hypothetical “publication mode”, i.e. hooks authors can eventually use be discussed with the CSS Working Group directly when it comes to some details? I mean there the Personalization TF, OK, but there’s also a lot of existing issues it doesn’t cover – this is quite a rabbit hole, isn’t it?

[avneeshsingh]

Lets pull out from the details and focus on the principles:

• Personalization is not confined to the personalization task force, it is a generic word and also involves all the good work being done by CSS group and may be other groups.
• In PWG affordances, we need to focus only on the additional requirements of WP/PWP over and above what the web already provides. This was an important decision to ensure that we are not reinventing the wheel.

This is why I kept on asking the question what aditional personalization should WP provide, over and above what web already offers. There was only one item that stood out, and that is application of personalization on whole WP instead of HTML page level personalization provided by the web.
But at the same time, it is possible that some content page in WP needs further personalization also e.g. if the font size is smaller than that on other content pages in WP.

This is the summary of the relevant discussions.

[clapierre]

@laudrain "I see functions belonging to the UA not the WP itself."
I agree with you, but we need to make sure that the WP "affords" the ability to personalize the WP by the UA/Reading System etc. If the WP locks out this ability by hard coding something which can not be personalized this is what we need to make sure doesn't happen.

[llemeurfr]

It may easier to use examples there: if the author's CSS is using !important on the font size of every textual elements, no UA CSS will be able to overwrite it, unless it also uses super-powers. But the spec cannot enforce that authors MUST not use !important in their CSS.

In this light, which affordances are we talking about? should we state that the WP (the content) must afford changing font, font sizes, colors ... what else?

!important: if we do that it will take a long time for authors to infer that it means "don't use !important on your CSS" ...

[mattgarrish]

we need to make sure that the WP "affords" the ability to personalize the WP by the UA/Reading System etc. If the WP locks out this ability by hard coding something which can not be personalized this is what we need to make sure doesn't happen.

Isn't this crossing over into content restrictions? EPUB limits the content to xhtml/svg because those formats allow personalization through the UA. It doesn't allow images in spine, for example, because those natively do not (or that's part of why they aren't allowed).

Web Publications afford personalization through the ability to encode content in formats that are conducive to "programmatic reconfiguration", but what more can we say? We don't want to prevent audio books, for example, which fall in what we describe as "optimized publications" but will have limited capabilities for customization.

Best practices and legal requirements to produce accessible content will be prime motivators to ensure that the right formats are chosen for the right situations.

[baldurbjarnason]

The only thing I'll add is that attempting to guarantee that the user can always personalise the publication no matter what the author puts in the stylesheet is a very deep rabbit hole as that essentially requires a fairly substantial change to how CSS is currently specified.

Which AFAICT leaves only two realistic alternatives:

1. Personalisation requires author participation of some sort (either avoiding certain value types or CSS features or some sort of direct hook). We can't force this participation but can make it easier and try to educate authors.
2. Personalisation requires a 'Reader' mode of sort similar to what browsers provide today that basically removes all author styles.

I don't see any other possibilities that are realistically feasible within the timeframe of this working group.

(Unless I'm completely misunderstanding the concerns in this thread, which may well be the case.)

[laudrain]

@baldurbjarnason I don't understand 2.

Personalisation requires a 'Reader' mode of sort similar to what browsers provide today that basically removes all author styles.

If the user changes the character size, why should all author styles be removed?

[llemeurfr]

@laudrain a "reader mode" tends to nuke the complete author's CSS. Therefore yes, such an option means that to be able to change one aspect like font size, the UA would have to take control of ALL aspects of the publication layout.

[baldurbjarnason]

@laudrain To elaborate on what @llemeurfr said:

CSS doesn't really incorporate the notion of the UA interjecting into arbitrary parts of the cascade. So you can change the underlying base font size or UA stylesheet, or you can have a user stylesheet that comes last in the cascade but none of those can account for the specifics of the author stylesheet that comes in between the two.

Like the author adding !important or #home .paragraph-style { font-size: 6px } for example.

Intervening into the author stylesheet without just nuking it entirely is pretty complicated and not really accounted for anywhere in any of the CSS specifications (that I know of) and is pretty much only done in the ebook ecosystem. Where it has caused nothing but trouble from day one.

Hence reader modes. They rely on the underlying element and accessibility semantics for structure and apply a generic user stylesheet on top which can be guaranteed to work with personalisation.

[laudrain]

@baldurbjarnason and @llemeurfr: I am clearly not an expert in CSS and Wed dev, then I am confused. Sorry for my questions but:

1. in EPUB Reading Systems today, the user can change font-size without seing all the author CSS nuked. Shall we loose this in WP?
2. is the Jiminy's tremendous work in Readium-CSS useless for WP ?

[llemeurfr]

@laudrain, not at all :-). All we said is that with the current technologies of the Web (i.e. CSS), in EPUB 3 like in WP, personalization (i.e. allowing the user to modify some layout parameters like font size, background color) is a fragile work, because there is a tension between the freedom of the author to use CSS as he likes and the wills of the end-user to modify what the author has coded, via the user's reading system (using e.g. Readium CSS as a tool).

I don't know how a spec like WP (but it's the same for EPUB 3) can specify in a practical way what the author can and cannot do. To state that "WP must afford personalization" is an imprecation: It does not give a clue about which type of personalization should be allowed, and how it can be achieved.

Detailing the first item in an comprehensive way (which type of personalization, e.g. font, font size, word spacing, line spacing, background color of EVERY resource in a WP ...) could be a good exercise. Only best practices can help authors learn about the second item.

[JayPanoz]

@laudrain what @baldurbjarnason and @llemeurfr said.

I’d perhaps add that font-size is kind of a complex case (and by very far not the simplest one). See this article from Archive.org by example.

To sum it up, there are basically two different ways to deal with font-size: the preference in the browser’s menu, see Chrome + Firefox.

Which can be ignored depending on the author’s stylesheet e.g. if font-size: 12px then your 20px base setting will be ignored.

And then there’s zoom e.g. cmd - option - + which behaves quite differently as it will zoom the entire page.

Note settings are very sparse in both. You can’t change the background-color, margins, etc. If you want to do that, Chrome tells you to pick an extension on their store for instance.

If you want eBook-like settings, they’re doing that in Reader Mode only, as they “normalize” web pages and can get around all the issues and never-ending list of edge cases we must deal with in EPUB.

Here’s Firefox’ Reader Mode:

You can check how Safari’s Reader Mode is doing things, you can use the web inspector to see they don’t even load the author’s stylesheets in this mode – note they may have obfuscated the script handling the transformation of the page for the reader mode.

That probably should be considered “prior art” in the case of more advanced settings. Given this and Baldur’s explanation, which I could only reword to make it less clear (😅), I can’t see how web publications can have their cake and eat it too when it comes to personalization. The simplest path could even well be re-using the reader mode to implement that affordance…

[JayPanoz]

Note also that a11y-related preferences can be managed at the OS level. In this case, authors can only use the media query (when supported) to adapt their styles depending on those preferences.

• ms-high-contrast-mode
• OS: High Contrast versus Inverted Colors
• Safari, Mac OS X et la gestion du monochrome (sorry in French)
• Dynamic Type in iOS

There’s also preferences for color-blindness for instance.

[clapierre]

I am worried about this "reading-mode" which would strip all author CSS, as there may be some specific CSS that some authors do to mark things they are hiding off-screen so that it can be accessed by a Screen Reader.
Such as:

.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}

Now maybe there is an argument that one should never hide anything off-screen and that this is a hack, but if you can no longer count on the original CSS being present that the same behavior could be accomplished with JavaScript alone to hide and unhide items.

[JayPanoz]

@clapierre at least some Reader Modes have heuristics to deal with that (and other things like list elements whose list-style-type is none) but yes, Reader Modes are quite an under-specified and under-standardized part of browsers indeed.

I know Ricky Mondello is working on Safari’s Reader Mode and tweeting about it so maybe he could give you some further details about that.

[wareid]

Affordances addressed in the UCR document, as mentioned in the meeting on Feb 4 2019, I am closing this issue.