Best Practice Tagging: Table reserved words

[jrbowden]

The Best Practice Tagging document, tables section currently states:

Reserved class values: listed, linear, stairstep Note that listed, linear, and stairstep are table types that are specific to North American braille formatting. Additional table types can be added. The use of these classes signifies the file creator's recommendation that a specific type of braille table formatting be used but the user or reading system may ignore this recommendation.

As for braille grade, I submit it is the CSS that should determine the behaviour and layout of the table, not the class name. Different regions may call very similar table layout by a different name. Thus in the UK, we have "paragraph" format, which is similar to one of the BANA formats.

I submit, there should be no reserved class names, but the CSS should determine the behaviour. I agree that the CSS should determine the default layout, as suggested in the text above.

[wfree-aph]

Thanks @jrbowden. The class name is what guides the CSS. The CSS will have rules for tables generally and then for tables with each class specifically. Transcribers make very specific decisions when formatting a book and so that's why I was thinking we'd want some mechanism for them to communicate their decisions.

I also want to add that the reserved class names don't limit what class names are possible. The author or creation tools can use basically whatever classes they want, they'll just need to have their CSS acknowledge what to do with those class names or there will be no point in adding those additional classes.

One potential option here is to reserve additional class names for table types that we know we need. I don't think we should set ourselves on the task of accounting for every possible kind of formatting but instead make it clear what's possible and make those possibilities as broadly applicable as we can. If we don't set out to make these decisions, programmers will and their decisions will be impossible to control and could make cross platform support for the file standard more difficult.

[mattgarrish]

I submit, there should be no reserved class names, but the CSS should determine the behaviour.

I believe the intention is to also provide a default style sheet for authors/authoring tools to use with these reserved class names, which would have to be linked from each content document, but that will come later. We had talked about making the styling part of the reading system earlier on, but that's not the case now.

There will also be an opportunity for regional localizations of the CSS, in which case the styling could be redefined using the cascade (e.g., the regional CSS could import the default style sheet and modify the classes as needed).

And if you want to ignore the work done to develop this styling and write everything yourself from scratch, that will be valid, too, although likely a laborious and repetitive task.

The core technology of an ebraille file, which we haven't really gotten into yet, is separate from content creation best practices, so the styles aren't binding restrictions.

[jrbowden]

I agree with @mattgarrish, it is the CSS that determines the behaviour, the class names can be anything. Obviously, any class referenced in the content must have valid CSS definition in the style sheet(s). If not, it is a validation error.