DR 13:0013: Proposed solution to "the blue ones"

Mon Aug 25 23:52:07 CEST 2014

Thanks for taking a thorough look at this.

I think you're right about the extra themeShade items - my way of finding the differences was to dig through our implementer notes looking for places where we called out different behavior - however, we seem to have missed those ones. I've added them to the draft.

On @color... per each instance you mention:

*         17.2.1: my solution (which I haven't shared yet) doesn't involve the style hierarchy at all, so I think this one is fine.

*         17.3.4: This was fixed in the yellow bucket by applying a default of "auto" to the CT. However, looking at the other ones you brought up, this doesn't seem to be the way they were handled typically in prose before. It would appear the default was described there... so I've moved this one into the blue bucket and resolved it this way instead. It does beg the question of whether there are other instances where behavior that could be captured in schema is documented in prose, but I don't want to try and resolve that in this DR. The style hierarchy aspects, especially, make it non-trivial.

*         17.3.5: This attribute isn't mentioned in the yellow bucket, but it is optional with no default. However, behaviour is actually covered in the prose ("If this attribute is omitted, then its value shall be assumed to be auto").

*         17.6.2, 17.6.7, 17.6.15, 17.6.21: The attribute isn't mentioned in the yellow bucket, but I agree that it's optional with no behavior supplied. I've added these to the proposed blue ones.

*         I've gone through the rest of the document and I believe you've captured all the instances

On @themeColor:

*         17.3.5: I think we're actually good with the current wording. The item was incorrect because of an "element" / "attribute" switch.

*         17.3.2.40, 17.3.4, 17.6.2, 17.6.7, 17.6.15, 17.6.21: In these instances, @themeColor does state that it's only used as an override for @color. We formerly didn't specify what the default for @color was, but I think this has been fixed by the additive changes made above to the blue bucketed items. So I don't think we need any further changes here.

*         17.2.1: This also fell back onto the @color setting, but its behaviour wasn't described when @color was missing. So I've added that.

*         17.3.5: This fell back onto the @color setting, but its behaviour was indeed already described in the standard.

I've attached an updated "blue ones". I also modified the yellow ones, but only to remove the default for "color" in CT_Border, so probably no need to attach the full text.

Chris

From: Francis Cave [mailto:francis at franciscave.com]
Sent: 19 August 2014 01:56
To: Chris Rae; e-SC34-WG4 at ecma-international.org
Subject: RE: DR 13:0013: Proposed solution to "the blue ones"

Hi Chris

This looks good.

I've done a trawl for @themeShade in Part 1, and I think that there are other occurrences needing the same treatment in 17.6.2 bottom (Bottom Border), 17.6.7 left (Left Border), 17.6.15 right (Right Border), 17.6.21 top (Top Border) and 17.15.2.5 color (Frameset Splitter Color).

I note that you have addressed @color in the case of 17.3.2.40 u (Underline), and I wonder whether the treatment of @color in other cases should be similar. There is one instance of @color is in the green bucket: 17.2.1 background (Document Background). Other instances of @color are in the yellow bucket: 17.3.4, 17.3.5, 17.6.2, 17.6.7, 17.6.15 and 17.6.21 . There's another instance of @color in 17.3.5 that we may have overlooked.

I'm also now wondering whether @themeColor is being correctly specified in all instances. We already have a proposed correction of @themeColor that occurs in 17.3.5 (DR 14-0002 - purple bucket), in which we now have:

If this element attribute is omitted, then no theme color is applied, and the color attribute shall be used to determine the shading pattern color.

Would this same wording be appropriate to add in other instances of @themeColor, i.e. 17.2.1, 17.3.2.40, 17.3.4, 17.3.5, 17.6.2, 17.6.7, 17.6.15 and 17.6.21?

It might be worth checking all uses of @color and @themeColor for consistency. Maybe we could discuss this briefly on Thursday's call.

Kind regards,

Francis

-----Original Message-----
From: Chris Rae [mailto:Chris.Rae at microsoft.com]
Sent: 18 August 2014 19:26
To: e-SC34-WG4 at ecma-international.org<mailto:e-SC34-WG4 at ecma-international.org>
Subject: DR 13:0013: Proposed solution to "the blue ones"

Attached are my proposed changes for the "blue" DR 13-0013 (https://onedrive.live.com/view.aspx/Public Documents/2013/DR-13-0013.docx) changes. These are ones for which prose needed to be added to the standard to cover behavior (i.e. this could not be represented in schema).

I've attached my changes - as part of the work I scanned Office's implementer notes and found one more example of the themeShade/themeTint behavior that many of these items represent. I've made a comment on that particular change.

Also attached is a test document I used to verify the behavior of the optional column width settings.

At this point, the only bucket I have left is the green ones. Although they're the ones marked as "need individual investigation" and there are 24 of them, so I might not make amazingly fast progress. I'm still anticipating being done by Kyoto, as promised.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140825/50569291/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: changes for DR-13-0013 (blue ones only).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 48636 bytes
Desc: changes for DR-13-0013 (blue ones only).docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140825/50569291/attachment-0001.docx>