Re: [cssom-view] addMediumListener / removeMediumListener

2010/5/31 Anne van Kesteren <annevk@opera.com>

> On Thu, 27 May 2010 17:59:32 +0200, Simon Fraser <smfr@me.com> wrote:
>
>> It would be better to change it to matchMedia() now, rather than later,
>> since not many people are using this yet. I hope we can avoid more renames,
>> though. Or, if we accept media query lists, maybe it should just be be
>> matchQueryList(), which I think is easier to read than the awkward
>> "matchMedium". matchQuery() would also work OK.
>>
>
> Given those I guess we should go with matchMedia / addMediaListener /
> removeMediaListener to match @media and media="" which both also accept
> media query lists.
>

I prefer Media instead of Medium as well.


>
> Then we need to answer the question how to compare media query lists. The
> suggestions from Luiz make sense but would also affect what
> MediaList.mediaText returns. The order would suddenly be different. But
> although that difference may seem larger I suppose it is not very different
> from the other normalization steps that are taking place.


That media list serialization proposal was based on what is now done for
media queries. As the serialization of the media list is composed by the
serializations of the queries in the list, the MediaList.mediaText may not
be expected to be the original string. The idea is to consider all media
lists that will always evaluate equal to be equal.


>
>
>
>  I'm  a little concerned about using a BooleanCallback here. I agree that
>> there's an issue where the serialized query may not match what was
>> originally used to add the listener, but I think having some context in the
>> callback is necessary. This allows people writing OOP JS to have a single
>> object with a handleEvent() function which can act as a listener for
>> multiple queries. This would be slightly easier if there were an easy way to
>> re-serialize a query (i.e. to convert it to its canonical form) via some
>> API.
>>
>> A slightly hacky alternative would be for addMediumListener() to return a
>> token (like setTimeout()) that can be used to identify which listener is it,
>> and gets passed to the callback.
>>
>
> Does that give a convenient API though? You would need to keep some table
> around with the mapping from token to media query list.


To be able to use the context information in the callbacks it is needed to
store it somehow anyway. The query may be stored in its canonical form or it
may be stored in its original form and converted every time a callback is
received. As the query serialization may be quite expensive that later
option may be not that good.

I think that to return a token to be used later to identify the callback is
ok.

We could make addMediaListener return the serialized media query. It could
then be used in the callbacks as a token, without considering its contents,
or as the media query if wanted. The parameters of removeMediaListener would
then be the pair (addMediaListener result, callback handler function) and
the parameters of the callback handlers would be the pair (addMediaListener
result, query result).

We could go back to having an object that exposes the serialized media query
> list. Getting a serialized media query list is easy enough by getting to a
> MediaList object somehow and getting its mediaText attribute. Don't think we
> need to create a convenient shorthand for that right away.



Luiz


>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>