Transforming text

[bertfrees]

Add a section describing how the transformation from text to braille can be controlled.

See http://snaekobbi.github.io/braille-css-spec/#h3_transforming-text.

[bertfrees]

This could be accomplished with a new 'text-transform' property.

It is not entirely clear yet what this property would look like and what it would mean.

There are two use cases for a 'text-transform' property, which are related, and in certain respects could even be considered equivalents. First there is the use case of selecting a translator based on translator features. And second there is the use case of controlling the translation of text segments using text attributes. In the latter case we're talking about one and the same translator that translates segments differently based on attributes, while in the former case we're talking about using different translators for different text nodes. But because we could think of a translator that would delegate to sub-translators based on text style, that distinction is a bit fuzzy.

Still, there remains the semantic difference between a "translator feature" and a "text attribute". A translator feature is something that belongs to the translator whereas a text attribute is something that belongs to the text.

Because the possibilities of such a 'text-transform' property are endless, it seems too restrictive to give it a well-defined meaning and form. The idea is to make it a general-purpose property and leave the interpretation up to implementations.

The value 'auto' is the default and means the UA makes a best effort based on all the available information. 'none' means text can not be transformed at all. This is the default if the UA is a renderer and not a translator.

In case of "translator features", it would make sense if the value could be a <translator query> (https://github.com/snaekobbi/braille-css-spec/issues/11). But in other cases a <custom-ident> or <ident-list> ( = [ <custom-ident> ]+ ) seems more appropriate.

Name	text-transform
Value	auto | none | ...
Initial	auto
Inherited	no
Applies to	all elements

[dkager]

Two questions:

1. Why is BrailleCSSDeclarationTransformer overriding a bunch of methods from the class it extends without changing the functionality? Example: processTextIndent().
2. What values did you come up with for TextTransform? It currently accepts an arbitrary list of values. I think this should be limited to {none, auto, uppercase, lowercase} for now. I think arbitrary values shouldn't be allowed at all (or what is a counter-example?).

Also, text-transform should probably be inherited. If I have <p><span>Some</span> text</p> I'd like to just say p { text-transform: lowercase; }

[bertfrees]

I wanted this property to be something generic with which you can precisely configure your (possibly custom) translator. The possible use cases of this property are endless, hence the arbitrary list of values. Rather than limiting the list of possible values and adding values as they are needed, I thought I'd allow everything and document new values somewhere as they are "standardized".

The rationale for this approach is that specifying the possible values and their meaning is not in the scope of Braille CSS because it can be so language and use case specific. Secondly: exactly specifying the behavior of values is not possible anyway and therefore doesn't fit so well with the rest of the spec which is in general very exact.

So maybe the definitions of values belong in some separate grammar which can possibly be overwritten or extended by other grammars?

[bertfrees]

Also, text-transform should probably be inherited.

'text-transform' is inherited, in a special way. It is already implemented, but hasn't been documented yet. Will do that shortly.

[bertfrees]

In my first comment I said:

There are two use cases for a 'text-transform' property ... First there is the use case of selecting a translator based on translator features. And second there is the use case of controlling the translation of text segments using text attributes.

In hindsight, trying to cover these two use cases is not such a good idea after all because it's too confusing. We should keep the distinction clear. Translator selection should be done only once, at top-level. A translator can be made highly controllable by having it support specific values for text-transform (i.e. text attributes/styles).

So <query> will not be allowed as a value, only [ <custom-ident> ]+.