CSS3-UI

This page is for collecting resolved issues for the CSS3-UI specification.

CSS3-UI Latest Released draft (REC since 2018): https://www.w3.org/TR/css-ui-3/
CSS3-UI Editor's draft: http://dev.w3.org/csswg/css3-ui/
Open Issues: https://wiki.csswg.org/spec/css3-ui
Pending More Edits (e.g. post draft publication): none
Issues for next version: https://wiki.csswg.org/spec/css4-ui

Resolved Issues

Collecting here for producing a disposition of comments upon exiting CR.

Issue 1

Summary: css3-ui should have a test suite
Raised by: Tantek Çelik
URL: eventually http://www.w3.org/Style/CSS/Test/#css3-ui
Proposed Resolution: create at least one test case per feature, update "Current Issues" section above to add the text See the [[1]] and [[2]] versions of the test suite for the "Tests" references.
Status: Resolved. LCWD has link to CSS Tests page. Update this to link to specific test suite page for CSS3-UI for the next CR. Pending next CR and contributions to test suite.

Issue 13

Summary: should CSS3 UI (or some future version) incorporate a 'focusable' property (like in SVG)
Raised by: Tantek Çelik
URL: http://www.w3.org/TR/SVGTiny12/interact.html#focusable-attr
Proposed resolution: postpone til CSS4-UI.
Status: Resolved. Added to http://wiki.csswg.org/spec/css4-ui#focusable-property

Issue 19

Summary: CSS3-UI should define 'overflow-x' and 'overflow-y' properties
Raised by: David Hyatt / Tantek Çelik
URL: http://lists.w3.org/Archives/Public/www-style/2010Nov/0049.html
URL: https://developer.mozilla.org/En/CSS/Overflow-x
URL: https://developer.mozilla.org/En/CSS/Overflow-y
URL: http://www.w3.org/Style/Group/css3-src/css3-box/#overflow
URL: http://www.w3.org/Style/Group/css2-src/visufx.html#overflow
Proposed Resolution: Postpone this to CSS4-UI or preferably CSS3-Box - whichever gets drafted/updated first: Define 'overflow-x' and 'overflow-y' properties already interoperably implemented by various browsers. Pull in entirety of [16 from CSS3 Box draft]. Sync (incorporate) any updates/changes [CSS 2.1 overflow definition]. Clarify: box-shadow should never trigger overflow/scrollbars. Clarify: do margins trigger overflow/scrollbars? Maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area. Consider: define baseline behavior as depending only on overflow-y per [O'Callahan / David Hyatt emails].
Newer alternative: There is now an overflow spec, this should go there: http://dev.w3.org/csswg/css-overflow/
Status: Resolved postponed to CSS3-Box or CSS4-UI.

Issue 30

Summary: Re-add ::selection, define according to existing impl interop of ::selection
Raised by: Tantek Çelik
URL: http://www.w3.org/2013/12/11-css-irc#T18-01-59 (recent IRC discussion)
URL: http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html (list of questions/issues with ::selection)
URL: https://developer.mozilla.org/en-US/docs/Web/CSS/::selection (documentation of current support)
URL: http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#UIfragments (most recent spec text)
URL: http://www.w3.org/TR/2004/CR-css3-ui-20040511/ (most recent CR reference)
URL: http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#UIfragments (most recent CR spec text)
URL: http://lists.w3.org/Archives/Public/www-style/2013Dec/0240.html (email about this proposal)
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg188 (2014 issues thread)
Proposed Resolution

Create tests to answer questions raised in http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
Run tests in browsers: Chrome, Firefox (as ::-moz-selection), IE9+, Opera, Safari
For all tests, if a majority of browsers agree on a test, codify that behavior into spec text. If not, explicitly list that test's behavior as undefined (browsers known to disagree)
Add resulting spec text to a new ::selection section in CSS3-UI.
Submit to CSS test-suite efforts each test where a majority of browsers agree on behavior.

Historical note: ::selection introduced as :selection 1999-09-16: http://www.w3.org/TR/1999/WD-css3-userint-19990916#pseudo-selection
Status: work on ::selection has been moved to (and is actively being done in) http://dev.w3.org/csswg/css-pseudo/

Issue 40

Summary: ime-mode is windows specific and bad design, and should not be standardized. (has replacement suggestion)
Raised by: Masayuki Nakano <masayuki@d-toybox.com> and James Craig <jcraig@apple.com>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0959.html Gecko ime-mode implementer saying should not be standardized
URL: http://lists.w3.org/Archives/Public/www-style/2013May/0075.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0072.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0090.html
Florian's Proposed resolution: drop ime-mode. It is not fully interoperable, and cannot become so cross platform.
Proposed Resolution: Document 'ime-mode' as officially obsoleted (that's a specific W3C term). Note the existence of implementations of a property with the name 'ime-mode', which may have some interop with some values on some platforms, but there are no tests to verify this, however there is documentation claiming non-interop ( https://developer.mozilla.org/en-US/docs/Web/CSS/ime-mode details of values, platforms, password field handling). Implementations MUST NOT add support for it. Implementations SHOULD drop support for it ASAP. Authors MUST NOT use it (it invalidates a style sheet). Users MAY use it only for "repair" use-cases where they have to work around bad sites and legacy implementations, e.g. with a user style sheet rule like: input[type=password] { ime-mode: auto !important; } . This specification deliberately does not attempt to document how legacy implementations work or what they support because it does not make sense to recommend any such path, nor to provide any legitimacy to those legacy implementations.
Updated Resolution: Implementations should not support the <css>ime-mode</css> property.
Status: Editor's draft updated with updated Resolution. Awaiting public draft.

Issue 47

Summary: The specced 'resize' property's behavior is *completely* different from the behavior implemented in browsers supporting the property
Raised by: François Remy
URL: http://lists.w3.org/Archives/Public/www-style/2012Dec/0221.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0063.html
Previous Resolution: allow behavior currently implemented by browsers and the one currently in the spec, amended to talk about a resize function instead of a resize factor
Proposed new Resolution: Note outstanding objection to "resize function" wording inline in the spec, link directly to email http://lists.w3.org/Archives/Public/www-style/2014Dec/0177.html Proposed text to resolve in favor of the objection here: https://lists.w3.org/Archives/Public/www-style/2015Feb/0149.html - proposed text goes beyond resolution. I have subsetted to only essential aspects in spirit with resolution, rewritten for better clarity, leaving in previous text unrelated to style attribute that had consensus.
Resolution: Specify must behavior of style attribute and pixels, due to implementation interop. (2015-02-10 f2f)
Status: Public draft published.

Issue 48

Summary: description of cursor: auto insufficient and not interoperable
Raised by: David Baron
URL: http://lists.w3.org/Archives/Public/www-style/2013Jan/0275.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0531.html
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0039.html (start of proposal)
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0182.html (issues, and previous in this thread too)
Proposed Resolution: Note this issue in spec explicitly with general plan to "restrict the auto value to handling things that cannot be described by the UA stylesheet." Proposal here, with analysis at the beginning, and proposed text at the bottom of the mail: https://lists.w3.org/Archives/Public/www-style/2015Feb/0039.html - note agreement on general plan, problems with details, proposal to be iterated offline.
Resolution: Apply proposal from dbaron, 'auto' behaves as 'text' over text, and 'default' otherwise, with inapplicability of cursor property over scrollbars, resizers, possibly other native UI widgets from input elements etc. (2015-02-10 f2f)
Status: Public draft published.

Issue 51

Summary: applying transforms to the outline is weird, especially in 3d.
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2013Aug/0423.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0134.html
URL: http://florian.rivoal.net/csswg/outline.html - test case that demonstrates applying transforms to outlines behaving strangely.
Resolution: Leave explicitly undefined for level 3 (2015-02-10 f2f)
Status: Public draft published.

Issue 52

Summary: behavior of resize on pseudo-elements buggy and ambiguously defined
Raised by: Lea Verou
URL: http://lists.w3.org/Archives/Public/www-style/2014Jul/0477.html
URL: http://dabblet.com/gist/ab432c3f6a8f672cd077 test case demonstrating non-interop / buggy behavior
Resolution: Explicitly note 'resize' does not apply to pseudo-elements. Note: may apply in the future if there is implementation of http://dev.w3.org/csswg/css-pseudo/#CSSPseudoElement-interface (2015-02-10 f2f)
Status: Public draft published.

Issue 66

Summary: Drop the pseudo-classes, they have a more up to date definition in selectors 4
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0228.html
Resolution: drop them. Patch here (shared with issue 65): http://lists.w3.org/Archives/Public/www-style/2014Dec/0200.html. Patch does too much, harder to verify than to do edits directly.
Status: Verified that http://dev.w3.org/csswg/selectors4 contains almost exact text copied from CSS3-UI sections #active ":active details", #indeterminate "The indeterminate-value pseudo-class :indeterminate", #pseudo-default ":default", #pseudo-validity ":valid and :invalid" (including XFORMS11 reference heh), #pseudo-range ":in-range and :out-of-range", #pseudo-required-value ":required and :optional". However Selectors 4 :read-only and :read-write definitions were completely different (likely newer). editor's draft updated. awaiting public draft.

Issue 69

Summary: box-sizing insufficiently specified for replaced elements
Raised by: Boris Zbarsky
URL: http://lists.w3.org/Archives/Public/www-style/2011Jul/0232.html
URL: https://lists.w3.org/Archives/Public/www-style/2011Jul/att-0232/test.html (test case from Boris, 100px intrinsic size, max-height 100, borders 40 + 40)
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html - two test pages, 3 tests each with/without box-sizing of SVG embedded images with intrinsic width and/or ratio.
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html - box-sizing test with different border-width and max-height values
Proposed Resolution: CSS 2.1 layout algorithm patched.
Status: Editor's draft updated. Pending public draft.

Issue 71

Summary: WG resolved to drop all XForms related pseudo elements from CSS-UI, but ::value and ::choices were retained, as they apply to HTML in addition to XForms as they were initially specified for. However, they are not implemented anywhere, and it is not clear that they effectively solve the problem they were introduced for.
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2014Nov/0401.html (drop XForms selectors resolution)
URL: https://lists.w3.org/Archives/Public/www-style/2015Jan/0046.html
URL: https://lists.w3.org/Archives/Public/www-style/2015Jan/0280.html
Resolution: Drop ::value and ::choices due to being underspecified (e.g. which properties should/must apply), and therefore being a potential source of many new issues (feature is too immature to be included in a LCCR).
Status: Public draft published.

Issue 72

Summary: All browsers should be treated equally with regards to obsoleting the 'ime-mode' property, instead of saying "must not add support" for those that don't have it but "should drop support" for those that do.
Raised by: David Baron (in telcon)
When: 2015-01-28
URL: http://www.w3.org/mid/CADhPm3uJkugzOcz-vaKXkFMGik=R2AXwxLmXaFtUj3E_HRnsyA@mail.gmail.com
URL: http://krijnhoetmer.nl/irc-logs/css/20150128#l-605
Proposed Resolution: Replace "Implementations must not add support for the ime-mode property. Implementations should drop support for it as soon as possible." with "User Agents should not support the ime-mode property".
Status: Public draft published.

Issue 75

Summary

As we mark ime-mode as obsolete, we should point readers of the spec to the alternative ways to address the issue that ime-mode was attempting to solve.

Raised by

Florian Rivoal

When

2015-01-28

URL

http://logs.csswg.org/irc.w3.org/css/2015-01-28/#e513809

Proposed Resolution

Add a note to ime-mode pointing readers to relevant html attributes, and explaining that dropping ime-mode was because it was a bad solution, not because the problem isn't worth addressing. Draft phrasing: "

The Working Group recognizes the importance of presenting the most relevant text input UI to users depending on what type of input is expected from them. However, instead of trying to control directly the UI as ime-mode attempts to do, a better approach is to give as much context as possible to the User Agent, and let it present the best UI possible to the user out of the various possibilities available on the platform. In HTML, the following attributes are relevant:

the lang attribute https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes
the type attribute of the input element https://html.spec.whatwg.org/multipage/forms.html#states-of-the-type-attribute.
The inputmode attribute https://html.spec.whatwg.org/multipage/forms.html#attr-fe-inputmode
the pattern attribute of the input element https://html.spec.whatwg.org/multipage/forms.html#the-pattern-attribute" - Shorter/briefer informative note wording that covers these features has been added to draft.

Status

Pending publication of existing editor's draft, then updated editor's draft, then another publication.

Issue 76

Summary: the change introduced to address #Issue 54 causes problems with bidi, scrolling, and is not necessarily an improvement anyway
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0007.html
Resolution: revert the change, invite proposals for another property/value to allow this. (2015-02-10 f2f)
Status: Public draft published.

Issue 77

Summary: text-overflow: clip should not clip at the end of the line box
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0342.html
Proposed Resolution: replace "Clip inline content that overflows" with "Clip inline content that overflows its block container element". This seems reasonable with the caveat that the "[...] its block container element" is a detail at risk pending implementation and web compatibility feedback.
Status: Public draft published.

Issue 78

Summary: Clarify that the :focus pseudo class matches when the focus is move to an element using the directional navigation properties, even if that element cannot otherwise be focused.
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0344.html
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0494.html (resolved during this telcon)
Proposed Resolution: Add normative text similar to: "If an element that is otherwise not focusable becomes focusable through the use of the directional focus navigation properties, the :focus pseudo-class matches this element when it is focused." and informative text explaining other options under consideration and welcome/actively soliciting input. Second, explicitly ask HTMLWG especially accessibility folks for input.
Status: Resolved at telcon 2015-02-25. Public draft published.

Issue 79

Summary: CSS3-UI "does not define" stacking behavior of outlines, but CSS2.1 and css-position do
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0357.html
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0494.html (resolved during this telcon)
Resolution: Add some normative text to make it explicit that the stacking of focus outline is left to the impl to provide better user experience per platform, and that this overrides CSS 2.1.
Status: Resolved at telcon 2015-02-25.

Issue 82

Summary: Drop the note and the at-risk mention about the "block container" aspect of the clip property, since it is the historic behavior implemented by everybody
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Mar/0053.html
Proposed Resolution: Drop the note and the at-risk mention about the "block container" aspect of the clip property
Status: Public draft published.

Issue 83

Summary: A couple of (mostly editorial) tweaks to the definition of the resize property
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Mar/0053.html
Proposed Resolution: see mail above
Status: Public draft published.

Issue 84

Summary: no file format required by the spec for cursor
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Mar/0199.html
Proposed Resolution: mandate .cur and .ico, all static image formats supported by the browser including SVG in secure static mode (if SVG is supported by the browser). Add a "should" requirement for animated images formats supported by the browsers (GIF, APNG, .ani) including SVG secure animated mode.
Status: Editor's draft updated.

Issue 85

Summary: Tiny leftover of nav-index removal should be erased
Raised by: Florian Rivoal
URL: http://www.w3.org/mid/D34E1BE4-AAF8-4229-B137-3D156BE9DA0C@rivoal.net
Proposed Resolution: http://www.w3.org/mid/D34E1BE4-AAF8-4229-B137-3D156BE9DA0C@rivoal.net
Status: Public draft published.

Issue 86

Summary: caret-color should be inherited, and auto should compute to auto
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0197.html
Proposed Resolution: Updated wording in editor's draft.
Status: Editor's draft updated. Pending public draft.

Issue 87

Summary: define what happens if a target-name starting with an "_" is provided
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0196.html
Proposed Resolution: proposed solution (b) in mail above.
Status: Editor's draft updated. Pending public draft.

Issue 88

Summary: incorrect prose (rtl issue) in in text-overflow
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0195.html
Proposed Resolution: patch in mail above, tweaked a bit for clarity
Status: Editor's draft updated. Pending public draft.

Issue 89

Summary: The precise direction of resizing is *not* left to the UA
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0194.html
Proposed Resolution: Clarify that resizing direction depends on CSS layout.
Status: Editor's draft updated. Pending public draft.

Issue 90

Summary: "the cursor’s coordinate system" is insufficiently defined for various <image> values
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0193.html
Resolution: Defer the defition of the coordinate systems to css-images
Status: Editor's draft update.

Issue 91

Summary: A few minor tweaks (essentially editorial) to css-ui
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0192.html
Proposed Resolution: most of the suggestions from the email.
Status: Editor's draft updated. Pending public draft.

Issue 92

Summary: In vertical text with text-orientation upright, U+2026 does not seem to be the best character for the ellipsis
Raised by: Xidorn Xuan
URL: http://www.w3.org/mid/CAMdq69_N1aGTswQM7807xoZSK4berTsqq5H-cg07AmbgBPjUFA@mail.gmail.com
Resolution: Allow UAs to take writing mode into account when choosing the ellipsis character.
Status: spec edited

Issue 93

Summary: "cursor: default" collides with the css-wide "default" value defined in css-cascade-4
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Apr/0329.html
Resolution: Keep cursor:default, research changing the css-wide "default" to something else. (telcon 2015-04-22)
Status: No change needed.

Issue 94

Summary: The default stylesheet for HTML should have "resize: both" for <textarea>
Raised by: Timeless
URL: http://www.w3.org/mid/CACsW8eGS3kZQ8a3jPAgrDaXW1WVmUQLo5vYzYty991JZzxMVdw@mail.gmail.com
Proposed Resolution: accept proposal, since all browsers that implement resize do this.
Status: 2015-06-10 WG telcon resolved to accept. Editor Draft updated to match.

Issue 96

Summary: Clarify the at-risk section
Raised by: timeless
URL: http://www.w3.org/mid/CACsW8eEQVD9K48FMt0UR7=c7S1=3LmX=itcnfc8UNE6WPRsBGg@mail.gmail.com
Proposed Resolution: Rephrased, and included more specific links, to make it more clear
Status: 2015-06-10 WG telcon deferred to Editors. Fixed in Editor draft

Issue 99

Summary: spec unclear as to what the limits of the area where the cursor should apply are when using border-radius
Raised by: Florian Rivoal
URL: http://www.w3.org/mid/020131AE-4EBD-4504-82A6-6C14C44A2DD8@rivoal.net
Proposed Resolution: clarify that the cursor applies within the border edge, to match implementations
Status: editor draft updated

Issue 100

Summary: Non standard error handling for unsupported cursor value considered harmful
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Jun/0195.html
Proposed Resolution: Delete offending sentence
Status: Editor draft fixed

...

(more to be filled in from https://wiki.csswg.org/spec/css3-ui )

Rejected Issues

Issue 49

Summary: there is no interop between UAs about showing tooltips of the ellipsed text
Raised by: Philip Walton
URL: http://lists.w3.org/Archives/Public/www-style/2013Apr/0013.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0532.html
Status: Rejected
Response: http://lists.w3.org/Archives/Public/www-style/2014Dec/0061.html

Issue 50

Summary: add user-select back to css3-ui, it has 3 implementations
Raised by: Tab Atkins and Edward O'Connor
URL: http://lists.w3.org/Archives/Public/www-style/2013Apr/0537.html
URL: http://lists.w3.org/Archives/Public/www-style/2012Jul/0541.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0536.html
Proposed Resolution: Defer to level 4, there's too much interop to figure out. Edit spec status section (near at risk features) noting this as an outstanding issue - user-select is at risk of being added back.
Updated Resolution: Consensus on deferring to level 4, remove any mention in CSS3-UI.
Status: Rejected.

Issue 55

Summary: Outline has a very loose definition, and significant interop problems. Should we tighten it up?
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0134.html
Resolution: Leave as defined in level 3. (2015-02-10 f2f)
Status: Resolved.

Issue 68

Summary: apply text-overflow even when overflow is visible?
Raised by: Mats Palmgren
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0425.html
URL: http://lists.w3.org/Archives/Public/www-style/2015Jan/0048.html
Resolution: No. CSS3-UI will stick with current restriction to overflow value other than visible. Too risky to expand to overflow:visible now, for implementability, and web compat. Leave for future levels to explore. (2015-02-10 f2f)
Status: No edit needed.

Issue 54

Summary: Can text-overflow ellipsis not break in the middle of a word?
Raised by: Stuart Langridge
URL: https://twitter.com/sil/status/537627213789949952
Proposed Resolution: Consider allowing implementation flexibility to ellipse at a text wrap opportunity instead of at a character boundary, and ask for further clarification (should this be automatic per implementation? or under author control). Add to spec "Implementations may ellipse at a text wrap opportunity instead of a character boundary."
Status: Published 2015-02-24. Subsequently re-opened (as issue 76) and removed in editor's draft per issue 76.

Issue 80

Summary: "Should drop ime-mode ASAP" is too strong as long as a better alternative has not been standardised
Raised by: Masayuki Nakano
URL: https://lists.w3.org/Archives/Public/www-style/2015Feb/0530.html
Proposed Resolution: change to "Implementation may keep supporting it *only* for backward compatibility until alternative feature is standardized" or "Implementation may keep supporting it *only* for backward compatibility until alternative features are sufficiently developed and supported"
Status: Duplicate. Group already resolved to drop "should drop" as part of issue 72 (and issue 40 updated) resolution.

Issue 95

Summary: "Ellipsed" isn't in the dictionary, use "Ellipsized" instead
Raised by: Timeless
URL: http://www.w3.org/mid/CACsW8eGS3kZQ8a3jPAgrDaXW1WVmUQLo5vYzYty991JZzxMVdw@mail.gmail.com
Proposed Resolution: reject, "Ellipsed" is in some dictionaries, "Ellipsized" is not
Status: 2015-06-10 WG telcon resolved to reject. Such editorial wording is up to editors.

Issue 97

Summary: Make stronger statement regarding authors disabling the outline on :focus
Raised by: timeless
URL: http://www.w3.org/mid/CACsW8eEQVD9K48FMt0UR7=c7S1=3LmX=itcnfc8UNE6WPRsBGg@mail.gmail.com
Proposed Resolution: Clarify why it is important, do not make threats of what third parties might do if this requirement is violated.
Status: Partly rejected. Clarifications to the existing warning made, and class=advisement applied, but 2015-06-10 WG telcon resolved to reject threat request, as out of scope for a W3C spec.

Issue 98

Summary: Add note saying the outline-color may be ignored if outline-style is auto
Raised by: Timeless
URL: http://www.w3.org/mid/CACsW8eEQVD9K48FMt0UR7=c7S1=3LmX=itcnfc8UNE6WPRsBGg@mail.gmail.com
Proposed Resolution: Reject, this is already stated 2 lines above.
Status: Editors consensus to reject.

Closed Issues

Resolved issues that have been reflected in a public CSS3-UI draft. E.g.

http://www.w3.org/TR/2015/WD-css3-ui-20150224/

Issue 2

Summary: Change name/title of spec to be consistent with other CSS3 modules
Raised by: Tantek Çelik
URL: n/a
Proposed Resolution: Change name/title of CSS3-ui from "CSS3 Basic User Interface Module" to "CSS Basic User Interface Module Level 3"
Status: Closed.

Issue 3

Summary: ::value needs to specify which properties are allowed on that pseudo-element
Raised by: Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2010Mar/0158.html
URL: http://www.w3.org/TR/css3-selectors/#first-line
Proposed Resolution: specify the same properties (by listing them explicitly) that apply to ::first-line as applying to ::value: 'font-*', 'color', 'background-*', ‘word-spacing’, ‘letter-spacing’, ‘text-decoration’, ‘vertical-align’, ‘text-transform’, ‘line-height’.
Status: Closed.

Issue 18

Summary: How does text-overflow:ellipsis work with overflow-style: marquee-line?
Dependency: Since CSS3 Marquee is already in CR and text-overflow is the "new" feature, it is up to text-overflow to define the interaction.
Raised by: Andrew Fedoniouk
URL: http://lists.w3.org/Archives/Public/www-style/2008Dec/0109.html
URL: http://www.w3.org/TR/2008/CR-css3-marquee-20081205/#overflow-style
Proposed Resolution: Render same as user controlled scrolling. Add mention of overflow-style to parenthetical examples listed after "When an element is scrolled".
Status: Resolved in http://www.w3.org/TR/2012/WD-css3-ui-20120117/
Update: CSS3 Marquee has been retired, as nobody implemented it and the WG does not encourage anyone to. This clarification is therefore not longer needed, and has been removed from the draft, along with all references to CSS3 Marquee

Issue 20

Summary: text-overflow definition is ambiguous as to whether it applies to vertical overflow of text
Raised by: Alan Hogan in private email to Tantek Çelik
URL: http://dev.w3.org/csswg/css3-ui/#text-overflow0
URL: http://dl.dropbox.com/u/105727/web/text-wrap-ellipsis.html
Proposed Resolution: No one has implemented text-overflow for anything other than inline progress. Therefore we should explicitly clarify this deatil. Insert "in its inline progression direction and " into "when text overflows its block container element that has ‘overflow’ other than ‘visible’" just after "element".
Status: Closed.

Issue 21

Summary: text-overflow definition must include <string> value and 2 values option, but with both explicitly at-risk.
Raised by: CSS WG
URL: http://dev.w3.org/csswg/css3-ui/#text-overflow0
URL: http://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html
Proposed Resolution: Update text-overflow definition to include <string> value and {1,2} values option as described below.
Status: Closed.

text-overflow string

text-overflow: <string>. consider incorporating dropped <string> value.

Originally text-overflow: <string> was [in CSS3 Text CR 2003-05-14] - but no one implemented it. Thus any request for including this MUST include some justification as to why/how implementations would consider it differently than they did (and reject) for CSS3 Text CR 2003.

Real-world use-cases:

none.

Theoretical use-cases:

text-overflow:"" can be used to clip inline content on whole characters (grapheme clusters) / atomic elements rather than clipping them at a pixel boundary. (is there any evidence of designers wanting such an effect?)
multilingual (need specific examples here. which languages and which characters?)
author might wish to use "(...)" for instance in citations (need a reference to this style of ellipsing in citations)
vertical ellipsis in maths (need a reference to this style of ellipsing in math)
a line that has nothing but images on it. Having two markers also motivates having a <string> value to be able to specify different symbols on each side.

CSSWG resolution: http://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html - in particular:

syntax: "RESOLVED: Add the two-value syntax to text-overflow in css3-ui, marked at-risk"
semantic: "two strings (left and right) in addition to one string (both)."
unprefixed: "[FF is] implementing it unprefixed, because everyone else already has."

Possible spec markup:

( clip | ellipsis |

  <a class="noxref" href="http://www.w3.org/TR/CSS21/syndata.html#value-def-string">
    <string></a> ){1,2}

...


           <string>


        Render the given string to represent clipped text. 
        The string is treated as an independent paragraph for bidi purposes.

...


[At risk]. If there is one value, use it for both the left and right line edges. 
If there are two values, use the first value for the right edge, 
and the second value for the left edge.

Issue 22

Summary: How should text selection behave in the presence of a text-overflow ellipsis?
Raised by: Tantek Çelik
URL: http://www.w3.org/Style/CSS/Tracker/issues/279
URL: http://lists.w3.org/Archives/Public/www-style/2012Nov/0263.html
Resolution: Selecting the ellipsis SHOULD select the ellipsed text. If all of ellipsed text is selected, UAs SHOULD show selection of ellipsis. Behavior of partially-selected elided text is up to UA. Consider adding clarifying examples in spec, adding tests. RESOLVED at 2012-10-30 TPAC CSSWG f2f meeting.
Status: Closed.
Notes: In Safari, you can see that the copy-pasted text is the complete text. This is what is expected by users, and implemented by other browsers.

Issue 23

Summary: Update CSS IS AWESOME example to show non-ellipsed last line.
Raised by: Rossen
URL: http://lists.w3.org/Archives/Public/www-style/2012Nov/0263.html
Resolution: Update CSS IS AWESOME text-overflow example in the spec to not ellipse the last line, but an earlier line. RESOLVED at 2012-10-30 TPAC CSSWG f2f meeting.
Status: Closed.

Issue 24

Summary: Provide horizontal scrolling text-overflow example revealing more text that is elided
Raised by: Tantek Çelik
URL: http://www.xanthir.com/etc/text-overflow.html
URL: http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0321.html
Resolution: Add horizontal scrolling text-overflow example akin to Tab's test case, note that it works in both Firefox and Opera (interop), but currently not in Webkit (Chrome, Safari). Decided to add two examples, with one text-overflow value, and with two to demonstrate the difference.
Note: was blocked by ambiguity in the spec, tracked as Issue 59, now resolved.
Status: Closed.

Issue 25

Summary: nav-index property is not well implemented, nor expected to be. also, is problematic (per similar issues on tabindex in HTML).
Raised by: Tantek Çelik
URL: here's one: http://lists.w3.org/Archives/Public/www-style/2012Oct/thread.html#msg468
URL: http://wiki.csswg.org/spec/css4-ui#nav-properties
URL: http://lists.w3.org/Archives/Public/www-style/2011Nov/0712.html
URL: https://wiki.csswg.org/ideas/nav-index
URL: http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg440 (continues following month)
URL: http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg441 (continues following month)
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0295.html
Resolution: drop nav-index property from CSS3-UI in next CR draft, move current text to a workspace page like I did for pointer-events: http://www.w3.org/wiki/User:Tantekelik#CSSWG , mark directional nav-* properties NOT at risk (note multiple implementations per http://www.w3.org/2013/11/27-css-irc ).
Status: Closed.

Issue 26

Summary: add 'cursor' values 'grab' and 'grabbing' per existing interop support by Gecko and -webkit- prefixed in WebKit
Raised by: Frank Yan / Tantek Çelik
URL: http://frankyan.com/labs/cursor/
URL: http://lists.w3.org/Archives/Public/www-style/2013Apr/0058.html
URL: http://lists.w3.org/Archives/Public/www-style/2013Apr/0428.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0319.html
URL: https://bugzilla.mozilla.org/show_bug.cgi?id=880672
Proposed Resolution: edit the spec, add the values, definitions, inline tests
Status: Closed.

Issue 27

Summary: specify that 'cursor' propagates from the root to the viewport
Raised by: Tab Atkins
URL: http://krijnhoetmer.nl/irc-logs/whatwg/20130523#l-684
URL: http://lists.w3.org/Archives/Public/www-style/2013May/0301.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0300.html
Proposed Resolution: Edit definition of 'cursor' to state (similar to how 'background' does [CSS3 Backgrounds]) that it propagates from the root element to the viewport. Patch in: http://lists.w3.org/Archives/Public/www-style/2014Nov/0300.html useful but a bit wordy. Simplified for readability.
Status: Closed.

Issue 28

Summary: link to nav-* directional navigation tests from nav-* section, and in tests section in header
Raised by: Tantek Çelik
URL: http://test.csswg.org/source/contributors/opera/submitted/css3-ui/
URL: http://lists.w3.org/Archives/Public/www-style/2013Nov/0271.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0299.html
URL: https://github.com/w3c/csswg-test/pull/372
Proposed Resolution: Edit spec accordingly, note in HTML (not)at-risk comments that Opera/Presto desktop supports nav-* directional navigation with "shift+arrow". No further edits needed, tests incorporated into test suite: http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/chapter-9.htm
Status: Closed.

Issue 29

Summary: nav-* directional navigation properties definition prose fixes
Raised by: Simon Sapin
URL: http://lists.w3.org/Archives/Public/www-style/2013Oct/0102.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0298.html
Proposed Resolution: Edit spec accordingly, explicitly say what happens if ID selector does not match any elements.
Status: Closed.

Issue 31

Summary: add 'caret-color' property at risk to css3-ui
Raised by: Andrey Rybka (Bloomberg) <arybka@bloomberg.net>
URL: Resolved http://lists.w3.org/Archives/Public/www-style/2014Oct/0260.html
URL: Initial proposal http://lists.w3.org/Archives/Public/www-style/2011Nov/0772.html
URL: 'auto' keyword computing to currentColor http://lists.w3.org/Archives/Public/www-style/2014Aug/0236.html
URL: Gecko intent https://bugzilla.mozilla.org/show_bug.cgi?id=1063162
URL: caret-* proposals http://lists.w3.org/Archives/Public/www-style/2014Sep/0172.html
Proposed Resolution: add 'caret-color' property with values color | 'auto', where 'auto' should compute to currentColor, mark entire feature at risk. Add 'caret' shorthand and other 'caret-*' properties to a feature proposal for CSS4-UI.
Status: Closed.
Resolved on: 2014-09-08

Issue 32

Summary: use line box edge instead of block container edge for the purpose of determining text-overflow
Raised by: David Baron
URL: https://bugzilla.mozilla.org/show_bug.cgi?id=944200#c3
URL: proposal http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html
URL: Tab says reasonable: http://lists.w3.org/Archives/Public/www-style/2014Feb/0141.html
URL: https://bugzilla.mozilla.org/show_bug.cgi?id=944200
URL: https://bugs.webkit.org/show_bug.cgi?id=115746
Proposed Resolution: change the opening sentence of text-overflow section from "overflows its block container element" to "overflows its line box edge", and any other similar references to block container edge to line box edge.
Status: Effective consensus from Webkit (per their fix of 115746), Chrome (Tab's email), Gecko (per 944200 discussion). Closed.

Issue 33

Summary: In the description of the <target-name> parameter of the nav-* properties, the word string should be replaced by <string>
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0708.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0442.html
Proposed Resolution: the word “string" should be replaced by "<string>”
Status: Closed.

Issue 34

Summary: The text-overflow property definition uses () for grouping, but we should use []
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0808.html
Proposed Resolution: patch in http://lists.w3.org/Archives/Public/www-style/2014Nov/0440.html
Status: Closed.

Issue 35

Summary: Editorial: distinguishing public web sites from web applications is non obvious
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0808.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0072.html
Proposed Resolution: ime-mode is being tombstoned (or possibly dropped) thus text in descriptions about "web applications" will be dropped.
Status: Closed.

Issue 36

Summary: "Content" properties for several input elements are locale specific
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0808.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0444.html
Proposed Resolution: add a comment saying so in the UA stylesheet for input[type=reset] and input[type=submit]. Proposed phrasing: "UAs should specialize this for the languages they support, using the :lang() selector". Since this is informative anyway, I just added the :lang(en) pseudo for those rules, and "per language" in the rule comment.
Status: Closed.

Issue 37

Summary: spec differs from implementations regarding whether resize only applies in 1 dimension if overflow-x or -y is visible in one of the dimensions.
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0713.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0445.html
Note: not sure how to get computed value of visible only in 1 dimension
Proposed Resolution: drop text regarding only applies in 1 dimension.
Status: Closed.

Issue 38

Summary: what to do if outline-offset is negative, especially to the point that the offset is more than half the element size or similar values that make it impossible to draw?
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0601.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0449.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0033.html
Proposed Resolution: "For negative values UAs should cause the outline to shrink into the border box. Neither the height nor the width of the shape drawn by the outline may become smaller than twice the computed value of the outline-width property, to make sure that an outline can be rendered even with large negative values. User Agents must apply this constraint independently in each dimension. If the outline is drawn as multiple disconnected shapes, this constraint applies to each shape separately. Negative values are an at risk feature." Justifications and variations in the mail linked to above, as well as tests showing existing non-interop.
Status: Closed.

Issue 39

Summary: Various issues with ime-mode
Raised by: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0759.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0072.html
Proposed Resolution: Since we're tombstoning (or dropping) ime-mode, none of these issues apply any more. No edits to make.
Status: Closed.

Issue 41

Summary: The 'inherit' value is globally defined for all properties, and the

preferred style appears to be to omit it in property definitions.

Raised by: Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2011Jul/0202.html
Proposed Resolution: patch in http://lists.w3.org/Archives/Public/www-style/2014Nov/0440.html
Status: Closed.

Issue 42

Summary: drop “inverted” from outline-color, webkit and gecko don’t do it
Raised by: Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2011Jul/0202.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0493.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0067.html - resolution
Resolution: Keep outline:inverted. Support is optional. Clarify that non supporting browsers must reject the value at parsing stage. See patch here: http://lists.w3.org/Archives/Public/www-style/2014Dec/0165.html. Patch applied manually.
Status: Closed.

Issue 43

Summary: add note or author conformance requirement to not make outlines invisible on focusable elements, for accessibility reasons
Raised by: Michael Cooper <cooper@w3.org>
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/1213.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0494.html
Resolution: add author conformance requirement forbidding to make outlines invisible on focused elements unless an alternative highlight mechanism is provided: "As the outline on elements in the ‘:focus’ state is depended on by keyboard users for interaction with the page, authors must not make the outline invisible on such elements without making sure an alternative highlighting mechanism is provided." - reworded with focus on keyboard users.
Status: Closed.

Issue 44

Summary: use <image> instead <uri> in the cursor property, like http://www.w3.org/TR/css3-background/#value-types. Allows high res images with image-set, gradients…
Raised by: Fantasai (responding to Tab Atkins) and Rick Byers
URL: http://lists.w3.org/Archives/Public/www-style/2011Jul/0202.html
URL: http://lists.w3.org/Archives/Public/www-style/2012Jul/0140.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0496.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0067.html - updated resolution
Resolution: see patch in http://lists.w3.org/Archives/Public/www-style/2014Dec/0164.html - patch ok except for uri/url rename which was avoided to limit change, and needing proper angle bracket escaping.
Status: Closed.

Issue 45

Summary: include an example highlighting the <target> part of the nav-* syntax. Suggestion: nav-up: #foo "bar"
Raised by: Yves Lafon
URL: http://lists.w3.org/Archives/Public/www-style/2012Oct/0499.html
Proposed Resolution: see patch in http://lists.w3.org/Archives/Public/www-style/2014Nov/0497.html. Patch example looks good, adjusted patch prose for better readability.
Status: Closed.

Issue 46

Summary: what happens if <x> and <y> are out of bounds for the cursor property
Raised by: Kang-Hao (Kenny) Lu and Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2012Feb/0712.html
URL: http://lists.w3.org/Archives/Public/www-style/2012Nov/0331.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0501.html
Resolution: Clamp, independently. Proposed phrasing: "If the coordinates of the hotspot, as specified either inside the image resource or by <x> and <y> values fall outside of the cursor image, they must be clamped (independently) to fit." Text looks good. Added.
Status: Closed.

Issue 53

Summary: resize factor behaviour is weird when width / height are later dynamically modified
Raised by: Lea Verou
URL: http://lists.w3.org/Archives/Public/www-style/2014Jul/0517.html
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0063.html
Proposed Resolution: Add proposed text from 0063.html, "allows the user to resize the element with no other constraints than what is imposed by min-width and max-width" - note at risk since FF only, link to 0063.html email with analysis.
Status: Closed.

Issue 56

Summary: WG resolved to make outline corners rounded to match borders, but it was only lightly discussed, and not obvious how that should work
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0145.html
Resolution: Add "To the extent that the outline follows the border edge, it should follow the border-radius curve" to level 3. Text looks good. Added.
Status: Closed.

Issue 57

Summary: the default object size for cursors is defined in CSS2.1, but not in CSS3-UI, which replaces it
Raised by: Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2010Dec/0080.html
Proposed Resolution: Add the following sentence to CSS3-UI's cursor section, under the <uri> value explanation: "The <a>default object size</a> for cursor images is a UA-defined size that should be based on the size of a typical cursor on the UA's operating system." Text looks good. Added.
Status: Closed.

Issue 58

Summary: border box is a well defined term. Let's use it.
Raised by: Fantasai
URL: http://www.w3.org/mid/4BF38810.2060005@inkedblade.net
Proposed Resolution: replace "when over the element’s border, padding, and content." with "when within the element's border-box". Looks good. Changed as suggested.
Status: Closed.

Issue 59

Summary: Spec is ambiguous as to what happens when the start end of the line overflows with a single value used on text-overflow
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0321.html (see point #2)
URL: http://lists.w3.org/Archives/Public/www-style/2011Sep/0504.html (webcompat single value end only)
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0342.html (Gecko preference in agreement)
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0346.html (Google pref in agreement)
Proposed Resolution: resolve ambiguity to say that single value only causes ellipsis at the end line edge. patch in http://lists.w3.org/Archives/Public/www-style/2014Dec/0154.html awkwardly worded, reworded using simpler language and existing "non-clip" terminology.
Note: blocks Issue 24
Status: Closed.

Issue 60

Summary: Information about when the resize factor gets reset is not sufficiently specific
Raised by: Boris Zbarsky
URL: http://lists.w3.org/Archives/Public/www-style/2004May/0222.html
Proposed Resolution: Trivial explicit use of computed value to disambiguate.
Status: Closed.

Issue 61

Summary: Cross reference should be updated to css3-background instead of css2.1
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0263.html
Proposed Resolution: update reference. patch in http://lists.w3.org/Archives/Public/www-style/2014Nov/0263.html. Patch looks good. Applied and added some whitespace.
Status: Closed.

Issue 62

Summary: Overview is redundant with Introduction, and introduction contains out of date sentence.
Raised by: Florian
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0434.html
Proposed Resolution: Delete overview, and first sentence of the introduction, move informal reference to WD-css3-userint-20000216 to introduction.
Status: Closed.

Issue 63

Summary: Section "Dependencies on other modules" is redundant with bibliography, but normative "Module interactions" section defining what the spec replaces is missing
Raised by: Florian
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0433.html
Proposed Resolution: replace “Dependencies on other modules” with “Module Interactions”. Patch attached in mail above. Patch looks good. Manually applied.
Status: Closed.

Issue 64

Summary: Drop the icon property and the icon value of the content property, they are not implemented.
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0230.html
Resolution: drop them. Patch here: http://lists.w3.org/Archives/Public/www-style/2014Dec/0198.html. Patch was insufficient, additional edits done manually.
Status: Closed.

Issue 65

Summary: Drop the XForms related pseudo-elements
Raised by: Florian Rivoal
URL: http://lists.w3.org/Archives/Public/www-style/2014Nov/0229.html
Resolution: drop them (in particular repeat-* pseudos). Patch here (shared with issue 66): http://lists.w3.org/Archives/Public/www-style/2014Dec/0200.html. Patch does too much, harder to verify than to simply do edits directly per resolution.
Status: Closed. awaiting public draft. Note: kept ::value and ::choices because they apply to HTML (especially HTML5), and Mozilla has an open bug to implement them, however dropped XForms related ::value example. Separate edit will add new examples for HTML5 inputs and ::value and ::choices.

Issue 67

Summary: Editorial improvement to clarify where the outline is
Raised by: Axel Dahmen
Raised on: 2014-12-08
URL: http://lists.w3.org/Archives/Public/www-style/2014Dec/0104.html
Proposed resolution: Add sentence after 'The outline created with the outline properties is drawn "over" a box[...]'. For example: "Note: This specification does not define the exact position or shape of the outline, but it is typically drawn immediately outside the border box". Text looks good - placement works better after "... conveying the concept of focus to the user." so I put it there.
Status: Closed.

Issue 70

Summary: CSS3-UI defines the 'default object size' for cursors, but not the 'concrete object size'
Raised by: Tab Atkins
URL: http://lists.w3.org/Archives/Public/www-style/2015Jan/0163.html
Proposed Resolution: Add the following sentence: "The <a>concrete object size</a> is determined using the <a>default sizing algorithm</a>. If an operating system is incapable of rendering a cursor above a given size, cursors larger than that size must be shrunk to within the OS-supported size bounds, while maintaining the cursor image's intrinsic ratio, if any."
Status: Closed.

Issue 73

Summary: Support for negative outline-offset is marked as optional and at-risk. However, all browsers that support outline-offset support negative values. The only issue was the lack of interop for large negative values. The new spec prose introduced to define interoperable behavior is fine.
Raised by: Florian Rivoal
When: 2015-01-28
URL: http://www.w3.org/mid/CADhPm3uJkugzOcz-vaKXkFMGik=R2AXwxLmXaFtUj3E_HRnsyA@mail.gmail.com
Proposed Resolution: Remove "UAs may ignore negative values. UAs that support " and mentions of "at risk". To deal with the risk of non implementation of the interoperable behavior in the CR time frame, replace "Neither [...] may become" with "Both [...] must not become".
Status: Closed.

Issue 74

Summary: The phrasing of what happens with large negative values in the outline-offset property is unclear, and makes it sound like we should keep a blank space of outline-width * 2 inside the outline at minimum.
Raised by: Fantasai
When: 2015-01-28
URL: https://lists.w3.org/Archives/Public/www-style/2015Jan/0581.html
Proposed Resolution: Clarify that outline-width * 2 is the outside dimension of the shape, wording up to editor.
Status: Closed.

Issue 81

Summary: A few (mostly editorial) tweaks to the definition of the resize property
Raised by: Florian Rivoal
URL: https://lists.w3.org/Archives/Public/www-style/2015Mar/0051.html
Proposed Resolution: Suggested changes seem overall reasonable - do edits that reflect intent of tweaks.
Additional Resolution: drop "should not apply" text, use this text similar to this instead: "As generated content pseudo elements do not have a <a>style attribute</a>, how they are affected by the 'resize' property is undefined, but UAs must not redirect the effect of the 'resize' property onto the parent element. Note: the resize property may apply to generated content in the future if there is implementation of Interface CSSPseudoElement."
Status: closed. Note: After publication, consider either drop the "should not apply" sentence, or rephrase to "does not apply" for CSS3-UI if we get interop (multiple do nothings).