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.

Sign up for GitHub

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

Jump to bottom

Property specified more than once on tt:initial #764

Closed
spoeschel opened this issue May 17, 2018 · 7 comments
Closed

Property specified more than once on tt:initial #764

spoeschel opened this issue May 17, 2018 · 7 comments
Labels
pr merged substantive
Milestone
1ED-CR2

Comments

@spoeschel
Copy link

The same property could be specified more than once on different tt:initial elements at the moment, e.g.:

...
<head>
  <styling>
    <initial tts:color="yellow"/>
    <initial tts:color="lime"/>
  <styling>
<head>
...

The Specified Style Set Processing in 10.5.4.2 in step 6.c....i currently says:

"if an initial element defines the initial value for P, then use that value"

So the expected behaviour in such a case should probably be deterministic. Or instead it should be forbidden that at the same time two tt:initial elements that set the same property can apply (e.g. with appropriate conditions added, which exclude each other, the above example would be fine).
@nigelmegitt
Copy link
Contributor

I'd propose to change the spec to permit zero or one initial element as a child of the styling element, instead of any number as is currently permitted..

@spoeschel
Copy link
Author

That would be my favorite solution tbh - however it would render the condition attribute on tt:initial useless. If that is acceptable though, then fine.

@spoeschel
Copy link
Author

Hmm OK...useless unless you want to switch between the default values and custom initial values.

@nigelmegitt
Copy link
Contributor

it would render the condition attribute on tt:initial useless

@spoeschel Oh yes, good point. That's actually useful functionality. Maybe we do need a way to resolve duplicate style attributes present in multiple initial elements after all. I'm not sure which algorithm to use - I guess the choices are "first specified" or "last specified", in document order.

@spoeschel
Copy link
Author

Yes, a way to resolve that ambiguity seems to be needed then. I'm no sure as well which of the two choices you mentioned is the better way. Maybe someone in the group is aware of a similar case and its solution. I currently cannot think of such a case already present in TTML itself.

@nigelmegitt
Copy link
Contributor

There's at least an analogy in resolving referential styles, where effectively the last specified attribute with a particular attribute name wins, and then if the style is specified locally on the current style, that wins. The closest fit to that pattern is to use "last specified" in document order.

@spoeschel
Copy link
Author

Indeed. So the "last specified" way seems to be more consistent here.

@skynavga skynavga removed the agenda label May 17, 2018
@skynavga skynavga added this to the CR2 milestone May 17, 2018
@skynavga skynavga self-assigned this May 18, 2018
skynavga added a commit that referenced this issue May 18, 2018
@skynavga
Clarify use of multiple specifications of initial value for the same …
1e358cc 
…property (#764).
@skynavga skynavga mentioned this issue May 18, 2018
Merged
@skynavga skynavga removed their assignment May 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
pr merged substantive
Projects
None yet
Milestone
1ED-CR2
Development

No branches or pull requests
3 participants
@skynavga @nigelmegitt @spoeschel