W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: [css-regions] Region.flowFrom throwing exception

From: Andrei Bucur <abucur@adobe.com>
Date: Wed, 1 Aug 2012 14:42:16 +0100
To: Alan Stearns <stearns@adobe.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CC3F0464.36DD9%abucur@adobe.com>
As long as there are ways to access the computed style of the region
container and there won't by any standalone Region objects, I agree the
flowFrom attribute is pretty useless. Option 1 seems to be the best.

However we should check for any weird behaviours in special cases such as
the region not being inserted in the DOM tree.

Andrei.

On 7/31/12 9:57 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 7/23/12 9:18 AM, "Andrei Bucur" <abucur@adobe.com> wrote:
>
>>Hello Alan!
>>
>>
>>The CSS Regions spec mentions that an exception is thrown when accessing
>>the properties of a Region that's no longer one (
>>http://dev.w3.org/csswg/css3-regions/#the-region-interface ).
>> However the flowFrom property looks to be more special to me because
>>with it throwing an exception it is difficult (getComputedStyle?) to
>>determine if an Element is region or not.
>>If flowFrom throws exceptions developers would often need to use
>>try/catch blocks which I don't think is recommended for an API
>>(exceptions hellę). However, it would be much more nice to be able to
>>wrap flowFrom in an IF statement and then use the Region
>> API without worrying about the object not being a region.
>>
>>
>>Thoughts?
>>Andrei
>
>Andrei,
>
>Since this information is already available through getComputedStyle,
>perhaps we do not actually need Region.flowFrom? Are there use cases for
>Region.flowFrom that are not served by getting the computed value of
>flow-from?
>
>I see three possibilities:
>
>1. Remove Region.flowFrom in favor of accessing the flow-from property
>using getComputedStyle
>
>This seems to be the best course of action to me, as we should only be
>adding to the OM when necessary.
>
>2. Retain Region.flowFrom with the current throwing behavior
>
>You can still use getComputedStyle if you want the simple branching, and
>you get consistent errors thrown on all Region interface members if you
>call them on a non-Region.
>
>3. Change Region.flowFrom to always return the computed value of the
>flow-into property
>
>This seems like duplication to me.
>
>Thanks,
>
>Alan
>
Received on Wednesday, 1 August 2012 13:42:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT