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

Character-related style properties should not apply to ruby containers. #1043

Closed
palemieux opened this issue Feb 6, 2019 · 24 comments
Closed

Character-related style properties should not apply to ruby containers. #1043

palemieux opened this issue Feb 6, 2019 · 24 comments
Labels
pr merged substantive
Milestone
2ED-CR

Comments

@palemieux
Copy link
Contributor

By definition, ruby containers (tts:ruby='container', tts:ruby='textContainer' and tts:ruby='baseContainer') do not have text node children. As a result, character-related style properties (see below) should not apply to them, just like they do not apply to p.

  • textEmphasis
  • textDecoration
  • textShadow
  • etc.
@skynavga
Copy link
Collaborator

@palemieux but do we need to say anything? since these containers do not have text node children it's a moot point, isn't it?

@skynavga skynavga changed the title Character-related style properties should not apply to ruby containers Character-related style properties should not apply to ruby containers. Mar 20, 2019
@skynavga
Copy link
Collaborator

@palemieux in particular, we don't say anything about character properties not applying to a span that contains no text nodes in non-ruby contexts, e.g., the outer span in

<span xml:id="outer"><span>A</span><span> </span><span>Word</span</span>

so why should we specify a constraint in a ruby container context?

@skynavga skynavga self-assigned this Mar 20, 2019
@skynavga skynavga added this to the 2ED-FPWD milestone Mar 20, 2019
@palemieux
Copy link
Contributor Author

so why should we specify a constraint in a ruby container context?

Because a ruby container context specifically explicitly prohibits the presence of meaningful (non-LWSP) text.

@skynavga
Copy link
Collaborator

That is no reason to add special case language saying that character properties don't apply to ruby (base or text) container spans. As you already admit, such containers don't contain non-LWSP text nodes, so there is already nothing to apply these properties to in the first place. In other words, adding language as you suggest is a NO-OP, and no different than observing that a (non-ruby context) span that contains no non-LWSP has nothing to apply character properties to.

@skynavga
Copy link
Collaborator

@palemieux could you supply a test file that tests such a constraint that you propose?

@palemieux
Copy link
Contributor Author

I would argue that stating that styles apply to elements for which they are nonsensical is defect of the model in and of itself, for the same reason that tts:fontStyle does not apply to region.

It also introduces ambiguities in the rendering the following snippet (note the xml:space="preserve"):

<?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="ja"
    xmlns:tt="http://www.w3.org/ns/ttml"
    xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
    xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling"
    xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
    ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text">
  <head>
    <metadata>
      <ttm:desc>Ruby container backgroundColor</ttm:desc>
    </metadata>
    <layout>
      <region tts:displayAlign="center" tts:textAlign="center" tts:backgroundColor="black" xml:id="r1" tts:position="center center" tts:extent="40% 40%"/>
    </layout>
  </head>
  <body>
    <div region="r1">
      <p begin="0s" end="1s">
        <span tts:ruby="container" xml:space="preserve" tts:backgroundColor="red">
          <span tts:ruby="base" tts:backgroundColor="black">利用許諾</span>
          <span tts:ruby="text" tts:backgroundColor="black">ライセンス</span>
        </span>
      </p>
    </div>
  </body>
</tt>

@skynavga
Copy link
Collaborator

I do not agree with your first statement

that styles apply to elements for which they are nonsensical is defect of the model in and of itself

In particular, we are talking about the span element here, to which character properties most certainly do apply (in general). Your claim is that because there is some case (e.g., when a span is marked as a ruby {base,text} container) that we should create special case language that negates the general rule for these special cases. But, except for your contrived example, there will never be a case where character properties would apply in these special cases.

Have you considered that the preserved LWSP in your example will be wrapped in anonymous spans by the [construct anonymous span] procedure, and, consequently, even in your example, the outer ruby container does not contain any text nodes to which character properties might apply?

I would suggest a different solution to the possible ambiguity you are worried about, which is to replace the the three instances of the following text that appears after Table 10-1

each of its text node children contain only <lwsp>;

with

each of its text node children contain only <lwsp>, which must be ignored for the purpose of presentation processing regardless of whether the computed value of xml:space is preserve or not;

@palemieux
Copy link
Contributor Author

Your claim is that because there is some case (e.g., when a span is marked as a ruby {base,text} container) that we should create special case language that negates the general rule for these special cases.

My argument is much simpler: just as tts:fontStyle does not apply to div, it should not apply to ruby containers.

@skynavga
Copy link
Collaborator

skynavga commented Apr 11, 2019 •
edited
Loading

But ruby container is not an element type. It is a style applied to span to which font styles apply in general. Adding language that states that "oh by the way, a span which is assigned a ruby container attribute value doesn't have any content characters to which font styles could apply" is not only unnecessary, but creates a special case not motivated by actual processing requirements. Furthermore, this doesn't deal with the treatment of the edge case of the presence of XML whitespace characters to which xml:space="preserve" might have been applied. My proposal for resolving this issue is simply to tweak the language I pointed out in #1043 (comment) above. We could also add a note (in 10.2.35.1) that reminds the reader that significant content characters do not appear as children of a span designated as a ruby container, and that, therefore, font related styles have nothing to apply to. What I am not willing to do is add special case semantics to every style property that applies to span that repeats this same information.

@palemieux
Copy link
Contributor Author

It is a style applied to span to which font styles apply in general.

The fact that a ruby container is expressed as <span tts:ruby='container'> instead of, say, <ruby> has never been clear to me -- perhaps it was merely an editorial preference. It does not change the fact that a ruby container cannot contain meaningful text nodes, just as a region cannot, and thus tts:fontStyle cannot apply.

@skynavga
Copy link
Collaborator

skynavga commented Apr 11, 2019 •
edited
Loading

No, not an editorial preference. It was based on a desire to provide interoperability with ARIB-TTML. See the arib-tt:ruby style attribute referenced in §3.1 of https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2342-1-2018-MSW-E.docx.

@skynavga
Copy link
Collaborator

skynavga commented Apr 11, 2019 via email

@palemieux
Copy link
Contributor Author

Good to know the background. It does not change the fact that a ruby container cannot contain meaningful text nodes, just as a region cannot, and thus tts:fontStyle cannot apply.

@skynavga
Copy link
Collaborator

You keep repeating yourself. I agree that tts:fontStyle doesn't apply. Where we don't appear to have agreement is whether it is necessary to point out the obvious or not. And if so, then how. I have proposed a specific approach. Shall I create a PR so we have something concrete to discuss?

@palemieux
Copy link
Contributor Author

I have proposed a specific approach.

I do not think the proposal at #1043 (comment) is adequate.

An approach similar to that in tts:rubyAlign, i.e. applies to: span only if the computed value of tts:ruby is container, is more explicit (and normative).

I am happy to propose a PR as well... as you prefer.

@skynavga
Copy link
Collaborator

I cannot accept your proposed approach since it entails making changes in too many points in the document, and, moreover, it remains my opinion that such language is technically unnecessary.

skynavga added a commit that referenced this issue Apr 12, 2019
@skynavga
Clarify non-applicability of character related styles in ruby contain…
09cd12e 
…er context (#1043).
@skynavga skynavga mentioned this issue Apr 12, 2019
Closed
@nigelmegitt nigelmegitt mentioned this issue Apr 23, 2019
Closed
palemieux added a commit that referenced this issue Apr 25, 2019
@palemieux
Clarify which style properties do not apply to ruby containers (#1043)
6c70bad
@palemieux palemieux mentioned this issue Apr 25, 2019
Closed
@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Character-related style properties should not apply to ruby containers. ttml2#1043.

The full IRC log of that discussion <nigel> Topic: Character-related style properties should not apply to ruby containers. ttml2#1043
<nigel> github: https://github.com//issues/1043
<cyril> glenn: on this one I posted a PR and haven't got a review
<cyril> pal: I reviewed it and proposed an alternative PR
<cyril> glenn: I'll take a look at that
<cyril> pal: my main question is really: does that match your understanding?
<cyril> ... my alternate PR want to be extremely explicit to see if we agree
<cyril> glenn: you want to address the possible ambiguity of white space preserve
<cyril> ... in anonymous text spans as children of these containers
<cyril> ... I hate dealing with dueling PR
<cyril> pal: you raised an interesting point
<cyril> ... another dimension of the issue is XML space
<cyril> ... and applicability, this is not a style property
<cyril> ... my alternative PR does not address that, so maybe we need to merge both PR
<cyril> nigel: on the point of XML space preserve, a naive interpretation means that there is character content
<cyril> glenn: basically, we don't want it to be
<cyril> ... it was never the intention that the text content of containers would be treated as text
<cyril> so I tweaked that in my PR
<cyril> ... another thing to keep in mind is that text nodes in containers will be wrapped in anonymous span, so there is no more character content directly in the container
<cyril> pal: I had not considered that when I filed the ticket
<cyril> ... maybe the 2 PRs are complementary
<cyril> ... nigel, what's your take on the white space issue?
<cyril> nigel: glenn's PR says that it ignores it
<cyril> ... my comment is broader, it's about any text, not white space
<cyril> glenn: there are already rules that rule out non-whitespace character
<cyril> ... are you asking about what happens when the content is invalid?
<cyril> nigel: yes
<cyril> glenn: in many cases, we don't specify what happens in case of error
<cyril> ... if you are a validating processor, you could reject
<cyril> nigel: I can see why you have the explicit exception about linear white space
<cyril> glenn: at that time I had not realized the ambiguity about preserve
<cyril> ... I want to reiterate
<cyril> ... since there are no character content that can appear as a child of container
<cyril> ... my original statement was that we don't need to say anything
<cyril> ... that's when he introduced the ambiguity about white space
<cyril> ... and since that is addressed, I think we don't need to say anything about properties that apply to character content
<cyril> ... that's why I don't think we need to put special case in each property for this
<cyril> nigel: but they do apply for inheritance
<cyril> glenn: right
<cyril> ... I pointed that out in the note
<cyril> pal: but inheritance is not application
<cyril> glenn: right, application means semantic application
<cyril> pal: like font-size does not apply to region
<cyril> ... my PR is to make it more explicit
<cyril> ... I do have a question about audio properties
<cyril> glenn: I do not like the approach of putting special case language in each property
<cyril> pal: you should consider the amount of change
<cyril> ... there's already special cases
<cyril> glenn: having repetition of the same statement in may properties is not a good thing
<cyril> s/may/many/
<cyril> summary: we'll continue reviewing the PR offline to reach consensus

@palemieux
Copy link
Contributor Author

Below is an example which, today, would result in an underline being applied to the text container -- as inherited from the ruby container:

<span tts:ruby="container" tts:textDecoration="underline">
 <span tts:ruby="baseContainer">
  <span tts:ruby="base">bonjour</span>
 </span>
 <span tts:ruby="textContainer">
  <span tts:ruby="text">hello</span>
 </span>
</span>

Is that really the intent?

0

@skynavga
Copy link
Collaborator

skynavga commented May 1, 2019 via email

@nigelmegitt nigelmegitt mentioned this issue May 2, 2019
Closed
@nigelmegitt
Copy link
Contributor

Note from today's call: @palemieux pointed out that in the image above, there are two underlines beneath the word "hello", one for the text itself and another for the textContainer span. The reason there are not two underlines beneath "bonjour" is unclear - it is possible that there are, but that they are in the same place as each other.

@css-meeting-bot
Copy link
Member

css-meeting-bot commented May 2, 2019 •
edited by nigelmegitt
Loading

The Timed Text Working Group just discussed TTML2 and TTML3 Pull Requests.

The full IRC log of that discussion <cyril> Topic: TTML2 and TTML3 Pull Requests
<cyril> github: https://github.com//issues/1043
<cyril> nigel: last time we said that we would deal with this offline
<cyril> pal: given that we are all here, we could have a shot at closing it
<cyril> glenn: let's spend 5 min
<cyril> pal: my homework was to review Glenn's PR
<cyril> ... there are 2 subtle points: text nodes being ignored and the applicability of styles to containers
<cyril> ... the PR that Glenn had proposed adresses both
<cyril> ... I'm happy with the way the PR adresses the first point
<cyril> ... not found a better way of doing it
<cyril> ... on the second part, I'm less happy
<cyril> ... it's buried in a note
<cyril> ... and it does not address specifically if a propery applies or not
<cyril> glenn: it's my opinion that if we define that LWSP is ignored in that context, irrespective of white-space attribute, for presentation
<cyril> ... and if we say that LWSP is forbidden
<cyril> ... we just need to add text for the error case
<cyril> pal: look at the example I posted in 1043
<cyril> ... there are 2 underlines that appear underneath hello
<cyril> nigel: I did not notice that before
<cyril> pal: my question is do we actually want text decoration to apply to the text container, ever
<cyril> glenn: you can construct an example that does not even involve ruby
<cyril> ... with outer spans and inner spans
<cyril> ... the intent of the specification is to not apply to all of them
<cyril> ... also similar to XSL FO
<cyril> pal: for div and p, this is obvious that it does not apply
<cyril> ... what I have not tried is the difference between inline block vs inline
<cyril> glenn: the semantic model for decoration in TTML is that it only applies to the most deeply nested text characters
<cyril> ... you don't have decorations applied to upper leve
<cyril> s/leve/level/
<cyril> ... ttpe does not do the behavior you are describing
<cyril> ... it may be an artefact of CSS or IMSC.js
<cyril> pal: I'm of hte same opinion
<cyril> ... that it does not apply to text container
<nigel> q+
<cyril> ... but I want it to be clear
<cyril> glenn: I'm not happy to have the same text in all properties
<cyril> ... I can tweak the note
<cyril> pal: that note is not sufficient
<cyril> ... it does not cover the case we are looking at right now
<cyril> nigel: Pierre's proposal very clearly is to add a clause to apply to to the various style attributes
<cyril> ... to add unless text container or ruby container
<cyril> ... any objection to that?
<cyril> glenn: we decided to avoid repetition
<cyril> nigel: you can refactor that to avoid repetition
<cyril> ... for example defining a term for a class of span
<nigel> ack n
<cyril> glenn: on this text decoration, I'm not sure that an interpretation of TTML2 can lead to that
<cyril> nigel: my reading of this is that you can interpret it that way
<cyril> ... if you think adding a normative statement is a no-op
<cyril> ... there should be no problem going ahead
<cyril> nigel: we are over time, we'll adjourn to same time next week

@nigelmegitt nigelmegitt mentioned this issue May 8, 2019
Closed
@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Character-related style properties should not apply to ruby containers. w3c/ttml2#1043.

The full IRC log of that discussion <nigel> Topic: Character-related style properties should not apply to ruby containers. #1043
<nigel> github: https://github.com//issues/1043
<nigel> Pierre: Although Glenn is not here, I'm interested in the perspective of other members.
<nigel> Nigel: I've been quiet up to now because I can see both sides and don't have a strong view.
<nigel> Pierre: This isn't about the white space handling - we have agreement on that.
<nigel> Nigel: Right, I think we should be super clear about which style attributes should generate no marks on the boxes
<nigel> .. generated by spans where ruby is container, textContainer or baseContainer.
<nigel> .. I would do it like in your pull request Pierre, or by refactoring the definition into a single place and creating a special
<nigel> .. term for those kind of span.
<nigel> Cyril: I like Glenn's pull request and Nigel's proposal too.
<nigel> Pierre: This is a real point of confusion because of the way Firefox handles it. TTML should be clear.
<nigel> .. I'm happy to repeat the text or use a definition. I actually started with a definition but didn't want another one but
<nigel> .. I'm really happy to recast the pull request with a definition, of a new kind of span, and use that.
<nigel> Pierre: Thanks for sharing your feedback.
<nigel> .. I'll update my pull request by putting in Glenn's text about linear whitespace etc.
<nigel> Nigel: Glenn has already made it clear he doesn't think the existing spec is for any marks to be made,
<nigel> .. but I haven't seen anything traceable there. Did you say your test only shows that in Firefox? What about Chrome or webkit?
<nigel> Pierre: They're so broken with ruby that I don't trust them.
<nigel> .. Glenn's argument is that text decoration only applies to terminal glyphs, but that's not always the case.
<nigel> .. I will update my pull request based on your feedback.
<nigel> .. Thanks.

@nigelmegitt nigelmegitt mentioned this issue May 22, 2019
Closed
@skynavga skynavga removed the agenda label May 23, 2019
@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Character-related style properties should not apply to ruby containers..

The full IRC log of that discussion <cyril> Topic: Character-related style properties should not apply to ruby containers.
<cyril> github: https://github.com//issues/1043
<cyril> nigel: can we get a resolution?
<cyril> glenn: the big picture I see is "applies to" is a CSS notion, formally defined in the CSS spec
<glenn> https://www.w3.org/TR/2011/REC-CSS2-20110607/about.html#applies-to
<cyril> ... it lists the elements to which the property applies
<cyril> ... we must note that a ruby container is not an element
<cyril> ... it is a specific span
<cyril> ... and then in CSS, all elements have all properties
<cyril> ... but some properties have no effect
<cyril> ... that's the guidance we get from CSS
<cyril> ... XSL-FO and TTML follow that
<cyril> ... applies to refers to element types and deals with rendering effect
<cyril> ... the question here is to add language to the 18 style properties to say that it does not apply to ruby containers
<nigel> q+ to note that TTML2 doesn't say that "applies to" is as per the CSS convention
<cyril> ... ie. the top level container, the ruby container and the text container
<cyril> ... my position is that we should not add this language
<cyril> ... the semantics depend on the content of the element
<cyril> ... the issue of rendering effect may or may not apply depending on other semantics
<cyril> ... having renderable text in it
<cyril> ... we added some language in my PR then in his PR
<cyril> ... we both seem to have agreed on language to say that it does not apply
<cyril> ... the only disagreement is whether or not to add language
<cyril> ... to the properties
<cyril> ... there are 3 properties to which it applies
<cyril> ... direction, unicode bidi and XXXX
<cyril> ... for the other 15, the semantics only apply to glyph areas
<cyril> ... the bottom line is that there was no case of a ruby container producing glyph areas to which these 15 properties could apply
<cyril> ... there is a semantic no-op
<nigel> q?
<cyril> ... in the interest of giving readers a clue, I did add a note to the PR
<cyril> ... in the 10.2.35.1
<cyril> ... that highlights for the reader that there is no significance to the fact that a property can apply
<cyril> ... I think my PR covers all the case
<cyril> ... with the exception of tweaking properties regarding the notion of glyph areas
<cyril> nigel: you described very clearly your thoughts process, which makes sense
<nigel> ack n
<Zakim> nigel, you wanted to note that TTML2 doesn't say that "applies to" is as per the CSS convention
<cyril> ... the need to clarify "applies to" is because there is some ambiguity
<cyril> ... for something like ruby-align, the "applies to" sets a precedent
<cyril> ... in giving more information
<glenn> q+
<cyril> ... the CSS spec is a bit interesting
<cyril> ... because it refers to conceptual things that are elements in HTML
<cyril> ... but not elements in TTML
<cyril> ... that makes me think we should be clearer in the spec
<cyril> ... we did it for ruby align
<cyril> ... we should be helpful for the other properties
<cyril> ... I wouldn't do that for tts:color saying that it applies to character content of an element, that's too obvious
<nigel> ack glenn
<cyril> glenn: so raised 3 things
<pal> q+
<cyril> ... we don't explicitly refer to the CSS definition of "applies to"
<cyril> ... that's true
<cyril> ... XSL-FO uses it without referring to it explicitly
<cyril> ... we have to balance use of references with clutter in the spec
<cyril> ... I could add a formal reference
<cyril> ... the 2nd point about ruby-align's precedence
<cyril> ... is a bad way to go
<cyril> ... my preference would be to remove the existing text in ruby-align (and the other one)
<cyril> ... we can embellish the prose to make it clear
<cyril> ... maybe that's part of why we are where we are
<cyril> ... turning 2 into 17 is a bad way to go
<cyril> ... it complicates tracking that semantics
<cyril> ... it clutters the table in my opinion
<cyril> the 3rd point is about clear to implementers
<cyril> ... the spec is not an implementation guide
<cyril> ... somebody can write one
<cyril> ... if you look at MPEG-2 systems spec, there is no information about implementation
<cyril> ... we are in good company when we don't put implementation details
<cyril> what I'm willing to do is add some text to conventions
<cyril> ... remove text from ruby align
<cyril> ... but not more
<nigel> ack pal
<cyril> pal: let's keep it simple
<cyril> ... "applies to" is extremely useful to implementers
<cyril> ... if a particular element is not on that list
<cyril> ... implementation can bypass it for rendering
<cyril> ... for instance that text-decoration is not on applies to for div, is already there and useful
<cyril> ... I see no reason not to continue on the path of listing things to what elements a property applies
<cyril> ... to the point that the ruby-containers are not "elements", that's knit-picking
<cyril> ... I think it's consistent and useful to list ruby containers on the list things to which a property applies or not applies
<cyril> cyril: I agree with listing them
<cyril> nigel: under the ruby attributes, there is a CSS mapping
<cyril> ... that's useful
<cyril> ... let's not forget that it's there
<cyril> glenn: even if we were to add something, we want to not repeat text
<cyril> ... style properties cannot apply to nothing
<cyril> pal: what about text-decoration?
<cyril> glenn: [explains underline and box model
<cyril> ... we have consistently done that in the spec
<cyril> ... they apply to span because applying to div is for inheritance
<cyril> pal: that's different, there is an inheritance line
<cyril> glenn: it's because it applies to the most nest glyph area
<cyril> s/nest/nested/
<cyril> pal: your logic doesn't work
<cyril> ... you say text decoration cannot apply to div because it would be confusing
<cyril> ... but you're saying the opposite for ruby container
<cyril> [scribe having problems following and scribing]
<cyril> glenn: when I reviewed all the 18 styles that are proposed to be changes
<cyril> ... both the text-decoration and text-emphasis properties have applies to glyph areas or inline ares
<cyril> ... the 15 properties do not have the same text
<cyril> ... my conclusion was that all 15 style properties, the semantics of those relate to glyph areas
<cyril> ... generated by anonymous spans or spans
<cyril> nigel: on the point of removing inline areas from text decoration
<cyril> ... CSS spec says, applies to all elements
<cyril> ... but there is specific text that says that underline only applies to text
<cyril> ... for example not on images
<cyril> ... but the difference between CSS and TTML is that CSS has blink
<cyril> glenn: I agree
<cyril> ... and I should handle that with a separate issue
<cyril> ... one could fathom having blink apply to a box
<cyril> ... in the CSS semantics
<cyril> ... so since we don't have blink, we could remove that
<cyril> ... I'll do that in another PR
<cyril> ... but that means that the 15 properties have languages that say that they apply to glyph area
<cyril> ... and since it's not possible to generate glyph areas in the ruby containers
<cyril> ... there is no logical way that it applies
<cyril> ... so it would be redundant and clutter
<cyril> ... that's the basis of my objection
<cyril> ... that's what I added in the note
<cyril> nigel: pal are you satisfied?
<cyril> pal: no
<cyril> ... text decoration is not on applies to for div, the same should apply to ruby containers
<cyril> ... I'm even more convinced
<cyril> nigel: as a chair, I see several people thinking additional text is needed and I see a single voice (glenn) thinking it is not needed
<cyril> glenn: for text decoration, I could add language or note in the prose
<cyril> ... and if pierre sees other properties where that is confusing, I could add text
<cyril> pal: I don't understand why we don't want to reuse the "applies to" line
<cyril> ... cyril suggested to use definitions to avoid wordy lines
<cyril> ... that's a good idea
<cyril> ... we shouldn't use prose gymnastics for that
<cyril> glenn: one cannot avoid reading the prose to understand the effect
<cyril> ... of rendering
<cyril> pal: right, but "applies to" is a bypass
<cyril> https://www.w3.org/TR/css-regions-1/#the-region-fragment-property
<nigel> scribe: nigel
<nigel> post-conversation-summary: The group was not able to find consensus at this time on how
<nigel> .. to progress, either procedurally or editorially.
<nigel> .. Glenn stated his willingness to adjust the prose for tts:textDecoration specifically and
<nigel> .. no other style attribute, to clarify that it does not have any effect on inline areas, but
<nigel> .. only on text.
<nigel> .. The group does have consensus on the handling of LWSP and for defining the usage of
<nigel> .. "applies to" as per CSS2's convention, and that style attributes that have rendering
<nigel> .. effects only on text content can be excluded from consideration by those ruby
<nigel> .. containers that are not permitted to contain text content.
<nigel> .. The remaining disagreement is whether or not to add qualifying text to those style
<nigel> .. attributes (normatively in the Applies to row of the style table) to describe this exclusion, with Glenn opposed, Cyril, Nigel and Pierre in favour.
<nigel> .. No clear path forward to resolve this at this time.

@skynavga skynavga mentioned this issue May 23, 2019
Closed
This was referenced May 29, 2019
Closed
Merged
@skynavga skynavga mentioned this issue Jun 23, 2019
Merged
@palemieux
Copy link
Contributor Author

Replaced by #1100 and #1129 and #1130

@palemieux palemieux mentioned this issue Jul 11, 2019
Closed
@skynavga skynavga removed their assignment Sep 20, 2019
@skynavga skynavga mentioned this issue Jan 16, 2020
Closed
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
2ED-CR
4 participants
@skynavga @palemieux @nigelmegitt @css-meeting-bot