See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)
The issue on
@described-at, and the role of this interest group on the relevant telco, has already been documented on the last meeting. The meeting itself happened last Thursday, the meeting minutes are also public. Deborah Kaplan gave a recap of the meeting.
The group produces a set of requirements that any solution should fulfill and this was presented at the meeting last week. The DPUB community accepts any solution that answer to these, although it must be consistent and without polyfills. Lots of publishers and related institutions were present, and that is by itself was important: it is the first time that the publishing was raising its voice in such a meeting in great numbers.
One thing that came out of this meeting is an agreement that it was too complicated to talk about backwards compatibility. Worrying about backwards compatibility was one of the things dragging us down. If you have newer tech, then you will be able to have access to this feature—but probably not in older browsers. (Unfortunately IE is now being considered an older browser, in spite of its wide presence, but Windows 10 and Edge may change the picture.)
It looks probable that the future will go towards the usage of the
details element. But that is not a conclusion yet: there are some technical issues with that elements, some features are still missing mainly due to its generalities (e.g., it is not clear which elements in a content is meant for accessibility and which one is present for some other purposes). The next step will be to produce requirement “grid” with issues, requirements, but also deployment plans (that grid will be created by the PF Working Group with an active participation of this group).
There was an agreement to publish the CSS Requirements Doc as a first public draft. This should happen later this week.
Chris Lilley gave a short intro to user style sheets. There are 3 sources for CSS in a page. User-agent, which it applies to all content. It was a polite fiction, but it actually works. Then there are the document stylesheets, then lastly with the highest priority are the stylesheets provided by the user. Been in since CSS1, and lets a user change font-size, etc. However, there are some problems. Firstly, it’s not consistently implemented (if at all). Users do not know they can do this—similarly to alternate stylesheets: the user interface aspects are essentially unsolved. Also, modern web content is heavily tweaked—so it’s easily broken. Lots of current web-design makes it so that changing styles could easily break things; meaning that user style sheet may not be the good place to do restyling. Another solution is browser preferences. This has the advantages that it isn’t in the cascade—but overrides things. Basically, the whole mechanism is fragile, and probably something else is needed.
(There are some work around the
@document rules in CSS 3, b.t.w., that may be helpful: this may allow per document styling on a browser level.)
There were some discussions on the fact that reading systems may represent a different constituency, where the user interface issues may be solved even if general browsers do not do it, but even if this was an acceptable route, the other problems remain. Indeed, even if the user interface allows a change (like many reading systems do with the change of character size or font families, for example) but its practical implementation may become extremely complex. (As an example, books cannot be submitted to Amazon with a
text-align property used, because that would make such changes too difficult for the Kindle…)
The way forward is to have a clear set or requirements on what the publishing industry needs for personalization; that document would help finding the right solution in the future. That has now become one of the new future deliverables for this group.