Re: Extending CSSOM Views matchMedium with callback
On Mon, 10 May 2010 19:56:41 +0200, L. David Baron dba...@dbaron.org wrote: On Monday 2010-05-10 10:27 -0700, Simon Fraser wrote: It feels to me like the correct solution would be enhance CSS OM somehow to allow authors to attach event listeners to CSSMediaRules somehow, so they can get notified when those @media statements start or stop matching. Making @media rules implement EventTarget sounds ok, as long as the events don't bubble. But is the main use case for this API actually people who already have @media rules, or people who want to do things separately from @media rules and would thus now have to go through the bother of adding some to a style sheet? (The CSSOM also isn't very good at giving you the rule object after adding a rule.) I might still lean towards an addMediaQueryListener/removeMediaQueryListener type API. Yeah, if @media was enough we would not have needed to provide the matchMedium() abstraction. styleMedia.addMediumListener(mq, callback) styleMedia.removeMediumListener(mq, callback) Sounds good to me. With the same semantics as addEventListener(). (I.e. duplicates removed, invoked in order of registration.) And as context information the media query and how it currently evaluates? What kind of representation for the media query? Serialized form? -- Anne van Kesteren http://annevankesteren.nl/
Re: Extending CSSOM Views matchMedium with callback
On Mon, 10 May 2010 19:47:42 +0200, João Eiras jo...@opera.com wrote: Should be addEventListener(mediaChanged, listener, false); There is already an event model, and it would just require a new event type. A generic event is not a good idea in my opinion. The more media features we add the more often it will be dispatched. Authors may not anticipate that. Furthermore, dispatching a bunch of viewport resizing events when the author is only interested in orientation change would be waste. -- Anne van Kesteren http://annevankesteren.nl/
Re: Extending CSSOM Views matchMedium with callback
On Tue, 11 May 2010 08:47:27 +0200, Anne van Kesteren ann...@opera.com wrote: On Mon, 10 May 2010 19:47:42 +0200, João Eiras jo...@opera.com wrote: Should be addEventListener(mediaChanged, listener, false); There is already an event model, and it would just require a new event type. A generic event is not a good idea in my opinion. The more media features we add the more often it will be dispatched. Authors may not anticipate that. Furthermore, dispatching a bunch of viewport resizing events when the author is only interested in orientation change would be waste. There was a misunderstanding on my part. My proposal, using addEventListener, is only for when media mode changes, like from screen to print. The other proposed API calls the listeners when a specific media query applies (which can include orientation and device width) and therefore not being quite implementable performantly. I would really like an event just for media change though, so we could deprecate onbeforeprint/onafterprint and therefore get a generic event that works for any media mode. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Extending CSSOM Views matchMedium with callback
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it possible to supply a JavaScript function to the
styleMedia.matchMedium(...) function.
As no exact IDL was proposed, I came up with one myself which I think fits the
use-case, and implemented the feature for WebKit.
The result of my work became the following IDL, for which I would like
comments/feedback:
interface MediaChangeListener {
void mediaChanged(in boolean queryResult);
};
interface StyleMedia {
readonly attribute DOMString type;
boolean matchMedium(in DOMString mediaquery, in MediaChangeListener
listener);
};
If listener is supplied to the matchMedium call then its mediaChanged method
will be called every time when then result of the expression given in
'mediaquery' changes. mediaChanged parameter queryResult receives the
current value (true/false) of the corresponding mediaquery.
The idea and actual implementation has already gone through some initial
feedback rounds in WebKit Bugzilla
(https://bugs.webkit.org/show_bug.cgi?id=37205)
Luiz
[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0071.html
Re: Extending CSSOM Views matchMedium with callback
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it possible to supply a JavaScript function to the
styleMedia.matchMedium(...) function.
As no exact IDL was proposed, I came up with one myself which I think fits the
use-case, and implemented the feature for WebKit.
The result of my work became the following IDL, for which I would like
comments/feedback:
interface MediaChangeListener {
void mediaChanged(in boolean queryResult);
};
interface StyleMedia {
readonly attribute DOMString type;
boolean matchMedium(in DOMString mediaquery, in MediaChangeListener
listener);
};
This seems reasonable to me, although I wonder if it's worth passing
a little more information to the listener, such as (a) the original
query or (b) the window. Would that be useful to authors, or are
they comfortable stuffing whatever is necessary in a closure?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Re: Extending CSSOM Views matchMedium with callback
I wonder if it makes sense to have another method for adding the
listener instead of abusing the already existing matchMedium. For
instance, calling matchMedium is going to evaluate the expression,
which is not really necessary.
Kenneth
On Mon, May 10, 2010 at 12:48 PM, L. David Baron dba...@dbaron.org wrote:
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it possible to supply a JavaScript function to the
styleMedia.matchMedium(...) function.
As no exact IDL was proposed, I came up with one myself which I think fits
the
use-case, and implemented the feature for WebKit.
The result of my work became the following IDL, for which I would like
comments/feedback:
interface MediaChangeListener {
void mediaChanged(in boolean queryResult);
};
interface StyleMedia {
readonly attribute DOMString type;
boolean matchMedium(in DOMString mediaquery, in MediaChangeListener
listener);
};
This seems reasonable to me, although I wonder if it's worth passing
a little more information to the listener, such as (a) the original
query or (b) the window. Would that be useful to authors, or are
they comfortable stuffing whatever is necessary in a closure?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
Re: Extending CSSOM Views matchMedium with callback
On May 10, 2010, at 8:48 AM, L. David Baron wrote:
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it possible to supply a JavaScript function to the
styleMedia.matchMedium(...) function.
As no exact IDL was proposed, I came up with one myself which I think fits
the
use-case, and implemented the feature for WebKit.
The result of my work became the following IDL, for which I would like
comments/feedback:
interface MediaChangeListener {
void mediaChanged(in boolean queryResult);
};
interface StyleMedia {
readonly attribute DOMString type;
boolean matchMedium(in DOMString mediaquery, in MediaChangeListener
listener);
};
This seems reasonable to me, although I wonder if it's worth passing
a little more information to the listener, such as (a) the original
query or (b) the window. Would that be useful to authors, or are
they comfortable stuffing whatever is necessary in a closure?
This simple callback-based mechanism suffers from various problems (of the type
that add/removeEventListener were designed to solve):
1. Unclear behavior when calling matchMedium() a second time for the same query,
with a different callback.
2. No way to remove a callback
3. Lack of context on the callback
I also think that forcing authors to call matchMedium() just in order to get
callbacks
when media queries change is not ideal.
It feels to me like the correct solution would be enhance CSS OM somehow to
allow
authors to attach event listeners to CSSMediaRules somehow, so they can get
notified
when those @media statements start or stop matching.
Simon
Re: Extending CSSOM Views matchMedium with callback
Hi Simon,
So what you are suggesting is a kind of
document.addMediaRuleListener(mediaquery, listener) etc? I think that
should be quite easy to implement.
Kenneth
On Mon, May 10, 2010 at 2:27 PM, Simon Fraser s...@me.com wrote:
On May 10, 2010, at 8:48 AM, L. David Baron wrote:
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it possible to supply a JavaScript function to the
styleMedia.matchMedium(...) function.
As no exact IDL was proposed, I came up with one myself which I think fits
the
use-case, and implemented the feature for WebKit.
The result of my work became the following IDL, for which I would like
comments/feedback:
interface MediaChangeListener {
void mediaChanged(in boolean queryResult);
};
interface StyleMedia {
readonly attribute DOMString type;
boolean matchMedium(in DOMString mediaquery, in MediaChangeListener
listener);
};
This seems reasonable to me, although I wonder if it's worth passing
a little more information to the listener, such as (a) the original
query or (b) the window. Would that be useful to authors, or are
they comfortable stuffing whatever is necessary in a closure?
This simple callback-based mechanism suffers from various problems (of the
type
that add/removeEventListener were designed to solve):
1. Unclear behavior when calling matchMedium() a second time for the same
query,
with a different callback.
2. No way to remove a callback
3. Lack of context on the callback
I also think that forcing authors to call matchMedium() just in order to get
callbacks
when media queries change is not ideal.
It feels to me like the correct solution would be enhance CSS OM somehow to
allow
authors to attach event listeners to CSSMediaRules somehow, so they can get
notified
when those @media statements start or stop matching.
Simon
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
Re: Extending CSSOM Views matchMedium with callback
Ola Joao, That would mean that the user would have to manually call all matchMedium queries the user is interested in to find out which one changed, without us being able to optimize this by not redoing the parsing of the queries etc. Att, Kenneth On Mon, May 10, 2010 at 2:47 PM, João Eiras jo...@opera.com wrote: On Mon, 10 May 2010 19:44:37 +0200, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi Simon, So what you are suggesting is a kind of document.addMediaRuleListener(mediaquery, listener) etc? I think that should be quite easy to implement. That seems quite a cludge. Should be addEventListener(mediaChanged, listener, false); There is already an event model, and it would just require a new event type. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/ -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
Re: Extending CSSOM Views matchMedium with callback
On Monday 2010-05-10 10:27 -0700, Simon Fraser wrote: This simple callback-based mechanism suffers from various problems (of the type that add/removeEventListener were designed to solve): 1. Unclear behavior when calling matchMedium() a second time for the same query, with a different callback. 2. No way to remove a callback 3. Lack of context on the callback Right. These are problems. It feels to me like the correct solution would be enhance CSS OM somehow to allow authors to attach event listeners to CSSMediaRules somehow, so they can get notified when those @media statements start or stop matching. Making @media rules implement EventTarget sounds ok, as long as the events don't bubble. But is the main use case for this API actually people who already have @media rules, or people who want to do things separately from @media rules and would thus now have to go through the bother of adding some to a style sheet? (The CSSOM also isn't very good at giving you the rule object after adding a rule.) I might still lean towards an addMediaQueryListener/removeMediaQueryListener type API. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Extending CSSOM Views matchMedium with callback
On Mon, 10 May 2010 19:53:52 +0200, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Ola Joao, That would mean that the user would have to manually call all matchMedium queries the user is interested in to find out which one changed, without us being able to optimize this by not redoing the parsing of the queries etc. Hardly an issue given that media change is not a bottleneck neither frequent, but more like a developer feature, or a UI toggle in the user agent (change to print preview for instance). So, I really don't see the point in making an optimization like this, if you can actually call it that. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Extending CSSOM Views matchMedium with callback
Though it will probably become more used due to the media features, such as (orientation:...), (view-mode:...) etc. especially on mobile devices. Anyway, I agree that it is not a bottleneck for the time being. Kenneth On Mon, May 10, 2010 at 3:11 PM, João Eiras jo...@opera.com wrote: On Mon, 10 May 2010 19:53:52 +0200, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Ola Joao, That would mean that the user would have to manually call all matchMedium queries the user is interested in to find out which one changed, without us being able to optimize this by not redoing the parsing of the queries etc. Hardly an issue given that media change is not a bottleneck neither frequent, but more like a developer feature, or a UI toggle in the user agent (change to print preview for instance). So, I really don't see the point in making an optimization like this, if you can actually call it that. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/ -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
Re: Extending CSSOM Views matchMedium with callback Re: CSS WG comments on View Modes Media Feature spec
All - FYI, I think the next steps here are to hash out some process
related issues so I started a related discussion on the public-
hypertext-cg mail list:
http://lists.w3.org/Archives/Public/public-hypertext-cg/2010AprJun/
0001.html
-Art Barstow
On Apr 12, 2010, at 4:12 PM, ext Marcos Caceres wrote:
On Apr 12, 2010, at 8:50 PM, Simon Fraser s...@me.com wrote:
On Apr 12, 2010, at 2:25 AM, Marcos Caceres wrote:
On Fri, Mar 26, 2010 at 2:25 PM, Marcos Caceres marc...@opera.com
wrote:
On Thu, Mar 18, 2010 at 4:02 PM, Simon Fraser s...@me.com wrote:
On Mar 18, 2010, at 6:44 AM, Marcos Caceres wrote:
4. all these queries could/should have an event-based
counterpart so the
changes are detectable by code. We understand this is outside
of the
scope of this spec but that's still an important comment.
We have a proposal already for the CSS WG to review:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
It seems like this needs to align to the current CSS OM View spec:
http://dev.w3.org/csswg/cssom-view/
which has a StyleMedia interface available on the window object
as 'styleMedia', rather than 'media'.
I would expect to see events related to media type changes in the
CSS OM View spec too, rather than in a widgets-related spec.
I totally agree, there is much overlap. We should start looking at
how
to merge the two specs (or our requirements) into the CSS OM View
spec. I would be happy for the widgets one to vanish if the CSS OM
View spec would handled our use cases.
Perhaps we should have a joint teleconf or something to arrange
how to
proceed... I'll leave that up to the chairs, however.
To make Widget View Modes Interfaces [1] redundant, we would like to
propose extending CSSOM Views' matchMedium method to have a callback
as a second argument.
This would address the following sections of [1] in the following
ways:
# 3.2. Media Type Changed Event Types
styleMedia.matchMedium(screen, function() { alert(no
longer screen!) })
# 3.3. View Mode Changed Event Types
styleMedia.matchMedium((viewmodesyntax), ... )
# 3.4. Resolution Changed Event Types
styleMedia.matchMedium((resolution:300dpi), ... )
# 3.5. Orientation Changed Event Types
styleMedia.matchMedium((orientation:landscape), ... )
The proposal has it's origins on the Mozilla bug list (see comment
from David Baron):
https://bugzilla.mozilla.org/show_bug.cgi?id=542058#c3
This is overlapping with ViewModeChanged events:
http://dev.w3.org/2006/waf/widgets-vm/vm-
interfaces.src.html#viewmodechangedeventtypes
Do we really need both?
No, we don't need both. To be clear, we want to kill off vm-
interfaces.src.html in favor of CSSOM Views (as we have shown that it
does more or less what we need).
Kind regards,
Marcos
Re: Extending CSSOM Views matchMedium with callback
On Tue, 13 Apr 2010 15:39:47 +0200, Arthur Barstow art.bars...@nokia.com wrote: All - FYI, I think the next steps here are to hash out some process related issues so I started a related discussion on the public- hypertext-cg mail list: http://lists.w3.org/Archives/Public/public-hypertext-cg/2010AprJun/0001.html I think more use case examples would still be good, but as I already indicated on IRC adding a callback to matchMedium that is invoked the moment the evaluation of the media query changes with respect to the current rendering view is not a big deal and certainly should not require charter discussion or a task force. The mailing list for CSSOM View is www-style and I don't really see a reason to change that either. -- Anne van Kesteren http://annevankesteren.nl/
Re: Extending CSSOM Views matchMedium with callback Re: CSS WG comments on View Modes Media Feature spec
On Apr 12, 2010, at 2:25 AM, Marcos Caceres wrote:
On Fri, Mar 26, 2010 at 2:25 PM, Marcos Caceres marc...@opera.com wrote:
On Thu, Mar 18, 2010 at 4:02 PM, Simon Fraser s...@me.com wrote:
On Mar 18, 2010, at 6:44 AM, Marcos Caceres wrote:
4. all these queries could/should have an event-based counterpart so the
changes are detectable by code. We understand this is outside of the
scope of this spec but that's still an important comment.
We have a proposal already for the CSS WG to review:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
It seems like this needs to align to the current CSS OM View spec:
http://dev.w3.org/csswg/cssom-view/
which has a StyleMedia interface available on the window object as
'styleMedia', rather than 'media'.
I would expect to see events related to media type changes in the CSS OM
View spec too, rather than in a widgets-related spec.
I totally agree, there is much overlap. We should start looking at how
to merge the two specs (or our requirements) into the CSS OM View
spec. I would be happy for the widgets one to vanish if the CSS OM
View spec would handled our use cases.
Perhaps we should have a joint teleconf or something to arrange how to
proceed... I'll leave that up to the chairs, however.
To make Widget View Modes Interfaces [1] redundant, we would like to
propose extending CSSOM Views' matchMedium method to have a callback
as a second argument.
This would address the following sections of [1] in the following ways:
# 3.2. Media Type Changed Event Types
styleMedia.matchMedium(screen, function() { alert(no
longer screen!) })
# 3.3. View Mode Changed Event Types
styleMedia.matchMedium((viewmodesyntax), ... )
# 3.4. Resolution Changed Event Types
styleMedia.matchMedium((resolution:300dpi), ... )
# 3.5. Orientation Changed Event Types
styleMedia.matchMedium((orientation:landscape), ... )
The proposal has it's origins on the Mozilla bug list (see comment
from David Baron):
https://bugzilla.mozilla.org/show_bug.cgi?id=542058#c3
This is overlapping with ViewModeChanged events:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html#viewmodechangedeventtypes
Do we really need both?
Simon
Re: Extending CSSOM Views matchMedium with callback Re: CSS WG comments on View Modes Media Feature spec
On Apr 12, 2010, at 8:50 PM, Simon Fraser s...@me.com wrote:
On Apr 12, 2010, at 2:25 AM, Marcos Caceres wrote:
On Fri, Mar 26, 2010 at 2:25 PM, Marcos Caceres marc...@opera.com
wrote:
On Thu, Mar 18, 2010 at 4:02 PM, Simon Fraser s...@me.com wrote:
On Mar 18, 2010, at 6:44 AM, Marcos Caceres wrote:
4. all these queries could/should have an event-based
counterpart so the
changes are detectable by code. We understand this is outside
of the
scope of this spec but that's still an important comment.
We have a proposal already for the CSS WG to review:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
It seems like this needs to align to the current CSS OM View spec:
http://dev.w3.org/csswg/cssom-view/
which has a StyleMedia interface available on the window object
as 'styleMedia', rather than 'media'.
I would expect to see events related to media type changes in the
CSS OM View spec too, rather than in a widgets-related spec.
I totally agree, there is much overlap. We should start looking at
how
to merge the two specs (or our requirements) into the CSS OM View
spec. I would be happy for the widgets one to vanish if the CSS OM
View spec would handled our use cases.
Perhaps we should have a joint teleconf or something to arrange
how to
proceed... I'll leave that up to the chairs, however.
To make Widget View Modes Interfaces [1] redundant, we would like to
propose extending CSSOM Views' matchMedium method to have a callback
as a second argument.
This would address the following sections of [1] in the following
ways:
# 3.2. Media Type Changed Event Types
styleMedia.matchMedium(screen, function() { alert(no
longer screen!) })
# 3.3. View Mode Changed Event Types
styleMedia.matchMedium((viewmodesyntax), ... )
# 3.4. Resolution Changed Event Types
styleMedia.matchMedium((resolution:300dpi), ... )
# 3.5. Orientation Changed Event Types
styleMedia.matchMedium((orientation:landscape), ... )
The proposal has it's origins on the Mozilla bug list (see comment
from David Baron):
https://bugzilla.mozilla.org/show_bug.cgi?id=542058#c3
This is overlapping with ViewModeChanged events:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html#viewmodechangedeventtypes
Do we really need both?
No, we don't need both. To be clear, we want to kill off vm-
interfaces.src.html in favor of CSSOM Views (as we have shown that it
does more or less what we need).
Kind regards,
Marcos
