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.

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

Change styling to use CSS. #444

Closed
tmichel07 opened this issue Oct 2, 2017 · 13 comments
Closed

Change styling to use CSS. #444

tmichel07 opened this issue Oct 2, 2017 · 13 comments

Comments

@tmichel07
Copy link
Contributor

@tmichel07 tmichel07 commented Oct 2, 2017

Comment sent byDavid Singer singer@apple.com
Date: Sat, 30 Sep 2017 17:49:32 -0700
https://lists.w3.org/Archives/Public/public-tt/2017Oct/0001.html

The styling model used in TTML2 is not CSS and is not processable by a processor/rendering-engine designed to support HTML/CSS. This leads to complex ‘come from’ process deep in rendering engines, where the behavior has to be dependent on whether the text ‘came from’ an HTML/CSS context or a TTML context.

Please consider adopting CSS as-is, without embellishment or improvement.

David Singer
Manager, Software Standards, Apple Inc.

@tmichel07 tmichel07 added the WR-pending label Oct 2, 2017
@tmichel07

This comment has been minimized.

Copy link
Contributor Author

@tmichel07 tmichel07 commented Oct 2, 2017

@skynavga skynavga changed the title TTML2 wide review comment: styling Change styling to use CSS. Oct 2, 2017
@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Oct 3, 2017

According to prior WG decisions, we have adopted in TTML style vocabulary based on XSL-FO and CSS. In doing so, we have made minor editorial changes to conform to the TTML camel case name convention, and, have, on occasion, added new keywords or value syntax as extensions. The WG has an active liaison with the CSS WG and is at present discussing a number of requirements as well as possible solutions that can be adopted; however, in the absence of solutions to requirements, new functionality has been defined in TTML as needed and this functionality has been proposed for adoption in CSS. The bottom line is that TTML must satisfy certain functional requirements whether or not they are satisfied by CSS, which is merely one possible vehicle for rendering TTML content.

@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Oct 3, 2017

As there is no practical action that can come from this issue as stated, other than restating the above design philosophy that has and continues to apply to TTML, I am closing this issue as works for me. The WG may wish to discuss at further length if needed.

@tmichel07

This comment has been minimized.

Copy link
Contributor Author

@tmichel07 tmichel07 commented Oct 3, 2017

@dwsinger

This comment has been minimized.

Copy link

@dwsinger dwsinger commented Oct 3, 2017

There is much practical action that can and should come from this. Look at the CSS compatibility at https://www.w3.org/wiki/TTML/CSSRequirements and weep, then start making changes to TTML to match what CSS does, instead of trying to 'improve', and work with the CSS group to get the features needed either for captions or better handling of styling in general, introduced into CSS.

@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Oct 3, 2017

So, we can't (or won't) change any of the following:

  • style property naming convention
  • existing TTML1 style property names or values

That limits any changes to new TTML2 style properties. Except for changes to align naming convention and semantic consistency, we have adopted XSL-FO or CSS keywords or value syntax for new properties. And, when insufficient functionality existed in CSS, we had to forge ahead, but have started a dialog with the CSS WG.

Rather than making blanket proposals about adopting CSS as is, I want to see case-by-case proposals that would arguably improve compatibility within the confines of the existing constraints and practice.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

@nigelmegitt nigelmegitt commented Oct 4, 2017

start making changes to TTML to match what CSS does, instead of trying to 'improve', and work with the CSS group to get the features needed either for captions or better handling of styling in general, introduced into CSS.

See #406 - I'm in progress doing the editing work for that to align with CSS semantics.

We are already working with the CSS group to get features needed added to CSS. When the WG has discussed the options and impacts of waiting for CSS to include the necessary features, there has been a clear consensus not to wait.

@dwsinger

This comment has been minimized.

Copy link

@dwsinger dwsinger commented Oct 4, 2017

re: "Rather than making blanket proposals about adopting CSS as is, I want to see case-by-case proposals that would arguably improve compatibility within the confines of the existing constraints and practice."

I think this reveals a major misconception that many of us have had for many years (including me): that captioning support is typically supplied by a native implementation that reads 'static' input files directly. Actually, in browsers at least, this is often far from the case; captioning is supported by polyfills etc. that translate the incoming format into HTML/CSS. When the semantics of the input cannot be matched in HTML/CSS, this becomes a nightmare. So the answer to the question is: every line that's not green in the https://www.w3.org/wiki/TTML/CSSRequirements page.

@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Oct 4, 2017

@dwsinger

This comment has been minimized.

Copy link

@dwsinger dwsinger commented Oct 4, 2017

As a distribution/archiving/etc. format this is indeed less problematic, and indeed the initial focus of TTML. Unfortunately it's being increasingly moved as a delivery format in a number of venues, so these questions then become very relevant.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

@nigelmegitt nigelmegitt commented Oct 12, 2017

As a disposition, I would propose something like:

Thank you for your review comment regarding TTML2 styling. Given the background of TTML we will not adopt CSS syntax as-is but continue with a TTML syntax that can in principle be mapped to CSS where that is helpful. We have identified some use cases which are not supported by CSS semantics; moreover it is not a requirement that presentation processors are implemented using CSS. However we agree that eventually it is desirable that all TTML style features can be mapped with fidelity to CSS equivalents, and will continue to work with the CSS WG towards achieving this goal. We would welcome all assistance in reaching this goal, including from browser implementers such as Apple.

@skynavga skynavga added the agenda label Dec 30, 2017
@skynavga skynavga added agenda and removed agenda labels Jan 8, 2018
@css-meeting-bot

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented Jan 9, 2018

The Working Group just discussed Change styling to use CSS. ttml2#444, and agreed to the following resolutions:

  • RESOLUTION: TTWG has taken steps towards CSS alignment including improving documentation of existing mappings, removing some non-mapped features, and working with the CSS WG to implement missing required features in CSS.
The full IRC log of that discussion <nigel> Topic: Change styling to use CSS. ttml2#444
<nigel> github: https://github.com//issues/444
<nigel> Pierre: I have implemented all of IMSC in a browser context with CSS.
<nigel> Nigel: We resolved a lot of this in #406 too.
<nigel> Cyril: And we resolved this morning to remove fillLineGap and multiRowAlign pending
<nigel> .. CSS.
<nigel> David: Those two changes are what we wanted - to get more alignment with CSS.
<nigel> Glenn: The direction does not include making backwards-incompatible changes.
<nigel> Cyril: also note https://www.w3.org/wiki/TimedText/CSSRequirements
<nigel> .. Disparity is not mappable to CSS and I don't think anyone is working on it.
<nigel> Nigel: Note that we had a useful joint meeting with CSS WG to proceed in the direction of
<nigel> .. compatibility with CSS at TPAC, and issues were filed in CSS.
<nigel> Cyril: There is action being taken on almost all of the "red" items in the CSS Requirements wiki.
<nigel> David: I propose: We have taken some steps, improved the documentation of mapping to CSS
<nigel> .. in the spec, removed some non-mapped features, and begun working with the CSS WG
<nigel> .. to implement missing features in CSS.
<nigel> .. I'm looking for a clear statement to move towards convergence.
<nigel> .. On that basis I'll accept this as the commenter.
<nigel> RESOLUTION: TTWG has taken steps towards CSS alignment including improving documentation of existing mappings, removing some non-mapped features, and working with the CSS WG to implement missing required features in CSS.
@dwsinger

This comment has been minimized.

Copy link

@dwsinger dwsinger commented Jan 9, 2018

I can accept that this is a goal and a work in process...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.