1469332 - Autocomplete for basic shapes like polygon() should fill in a useful value

Status: NEW

(DevTools :: Inspector: Rules, enhancement, P4)

Description

[Razvan Caliman [:rcaliman]]

CSS properties like clip-path and shape-outside support values of basic shape functions like circle(), polygon(), ellipse() and rect().

Accepting the value from the autocomplete popup will insert just the function name. Empty circle(), ellipse() and rect() are valid because the browser has implicit values for their coordinates.

However, the user needs to declare explicit coordinates for polygon(). Empty polygon() is invalid. The user needs to type in by hand a lengthy value in order to be able to start using the Shape Path Editor which operates only on valid values.

Autocomplete should be more helpful and provide a useful stater value for basic shapes:

// A 4-edge polygon (rectangle) around the element:
- polygon -> polygon(0 0, 100% 0, 100% 100%, 0 100%)

// Explicit declaration for circle center and radius
- circle -> circle(50% at 0 0)

// Explicit declaration for ellipse center, horizontal and vertical radius
- ellipse -> ellipse(50% 50% at 0 0)

// Explicit declaration of a rectangle without inset on any side
- rect -> rect(0, 0, 0, 0)

Comment 1

[Brad Werth [:bradwerth]]

I was curious how much of these defaults were fully defined in the spec. circle() and ellipse() are fully specified, and if we wanted to reflect that in the proposed starter shapes -- and I'm not sure we do want that -- they would read:

circle(closest-side at 50% 50%)
ellipse(closest-side closest-side at 50% 50%)

Due to the "at" locations, these would both be different shapes than proposed in comment 0. Also note that a default ellipse is a circle, not a maximal ellipse as proposed in comment 0.

inset() and polygon() both have no default, and consequently "inset()" or "polygon()" results in a parsing error. The parsing error generates a maximal float area, which is functionally identical to the proposed default inset(0 0 0 0). Since both parsing errors lead to reasonable behavior with maximal float area, I don't think there is any value in requesting a spec change to have defaults for those shapes.