Re: [css-ui] Definition and scope of 'resize' property

On Fri, Aug 19, 2011 at 6:37 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> I don't think CSS should be requiring the UA to alter the DOM. If the UA
> wants to
> treat resizing as an injection of width/height into the cascade rather than
> as a
> ratio, that's one thing. But altering the DOM is another. So far, the DOM
> has been
> a read-only object for the CSS model.

What alternative do you suggest?  That there be a special way of
overriding width/height that kicks in only for resize and is never
used elsewhere?  I'd be mildly surprised if implementers are willing
to do that, and it risks hopelessly confusing authors who are making
assumptions in their scripts or stylesheets.

There's no precedent for the user being able to directly modify CSS
things like height/width at all, really, other than things like
viewport size that the page has no control over to start with.  It
makes a lot more sense to reuse existing mechanisms as much as
possible and avoid creating new special cases, even if it means we
have to bend existing invariants.

Personally I don't care so much if the DOM is modified or not for
non-editable elements (although it has to be if the element is
editable).  But in the end, we really have to spec what implementers
implement.  So far, AFAIK, only Gecko and WebKit implement the resize
property, and they both do it by modifying the DOM.  Notably, they
modify the DOM differently: Gecko sets only height/width, WebKit also
sets margin (no idea why).  This is something that has to be
standardized.

On Fri, Aug 19, 2011 at 6:49 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> So, if you lift that restriction, you have to consider other things, e.g.
>  - effect on inline elements
>  - effect on blocks involved with margin collapsing

Correct me if I'm wrong, but if resize just lets the user add
height/width properties to the DOM, isn't all this already defined?
Of course, UAs might want to not expose UI for resizing on elements
where resizing would have no effect or strange effects.  But we can
define how resize behaves in all cases (= add width/height to inline
style) and then leave it up to UAs to decide which elements to support
it on.  Eventually interop on the set of supported cases would be
good, but it's not critical, since *mostly* this is a user convenience
feature that authors won't notice.

The aforesaid applies just as much if we don't allow DOM modifications
but instead act as though the DOM had been mutated by modifying the
cascade or whatnot.  As long as we define it as something equivalent
to particular inline style, we don't need to define special cases any
further.

Received on Monday, 22 August 2011 18:47:59 UTC