Re: :host pseudo-class
On Monday 2015-04-27 05:49 +0200, Anne van Kesteren wrote: > On Mon, Apr 27, 2015 at 5:37 AM, L. David Baron wrote: > > We haven't really used (in the sense of shipping across browsers) > > pseudo-elements before for things that are both tree-like (i.e., not > > ::first-letter, ::first-line, or ::selection) and not leaves of the > > tree. (Gecko doesn't implement any pseudo-elements that can have > > other selectors to their right. I'm not sure if other engines > > have.) > > > > I'd be a little worried about ease of implementation, and doing so > > without disabling a bunch of selector-related optimizations that > > we'd rather have. > > > > At some point we probably do want to have this sort of > > pseudo-element, but it's certainly adding an additional dependency > > on to this spec. > > Are you saying :host accepts selectors to its right and they would > potentially result in a match? Yes. For :host it's less interesting, but I thought a major use of :host() and :host-context() is to be able to write selectors that have combinators to the right of :host() or :host-context(). And I tend to think :host, :host(), and :host-context() should probably agree on whether to be pseudo-classes or pseudo-elements. > Even if that were the case it's still > unclear to me how a pseudo-class is justified. Or are you saying the > concept of a host element selector is problematic in general? No. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature
Re: :host pseudo-class
On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: > I don't understand why :host is a pseudo-class rather than a > pseudo-element. My mental model of a pseudo-class is that it allows > you to match an element based on a boolean internal slot of that > element. :host is not that since e.g. * does not match :host as I > understand it. That seems super weird. Why not just use ::host? > > Copying WebApps since this affects everyone caring about Shadow DOM. We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature
Re: [webcomponents]: Shadow DOM + CSS = <3 Meeting Summary
On Monday 2013-06-24 15:18 -0700, Dimitri Glazkov wrote: > You can find all of this (and more!) > in the minutes (http://www.w3.org/2013/06/21-webapps-minutes.html). That set of minutes isn't complete, because it was generated in the middle of the meeting rather than at the end. The complete log is at: http://www.w3.org/2013/06/21-webapps-irc.txt http://www.w3.org/2013/06/21-webapps-irc.html -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla http://www.mozilla.org/ π
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wednesday 2012-08-08 21:16 -0500, Glenn Maynard wrote: > APIs should always be shipped prefixed and unprefixed for a reasonable > period, so people have an opportunity to add the unprefixed name to their > site before the unprefixed name goes away. Except that authors don't notice that they need to do so until the unprefixed name goes away and causes pages to break. So it's better if that happens sooner rather than later, so fewer total authors will have to deal with the resulting broken pages. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla http://www.mozilla.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 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: [WebIDL] Bugs in DOMString conversion to Unichode characters (was Re: "send data using the Web Socket" and UCS-2)
On Wednesday 2009-07-01 13:02 +1000, Cameron McCormack wrote: > I meant to do that initially, dunno what went wrong. Should be fixed > now. > > http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode Looks good to me. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[WebIDL] Bugs in DOMString conversion to Unichode characters (was Re: "send data using the Web Socket" and UCS-2)
On Wednesday 2009-06-17 16:26 +1000, Cameron McCormack wrote: > Jonas Sicking: > > Yes, I don't see how we could handle this in WebIDL, other than > > defining that all DOMStrings must be structurally correct UTF-16. > > However that would be prohibitively expensive since we would have to > > add checks in many many places. > > I agree, I donβt think it would be good to require this. > > Anne van Kesteren: > > Web IDL could define algorithms how you convert a DOMString to and > > from UTF-8. And maybe other encodings if that is desirable. > > I added a simple algorithm that converts a sequence of 16 bit code units > to a sequence of Unicode characters, inserting U+FFFD characters when > bad surrogates are used: > > http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode > > Nothing in Web IDL references this algorithm. Other specs can do so if > it is useful. This algorithm seems incorrect in two ways: * It gets the ranges for high and low surrogates backwards. (High surrogates are U+D800 - U+DBFF, low surrogates are U+DC00 - U+DFFF, and in UTF-16 a surrogate pair is a high surrogate followed by a low surrogate. So swapping the ranges in the headings should make the algorithm correct, modulo the next point. But you should definitely double-check this. :-) * It incorrectly handles unpaired high surrogates by eating the next character. Instead, I would prefer that the unpaired high surrogate is replaced by U+FFFD, and the following character is interpreted normally. (That's what Gecko does, anyway. Furthermore, I think it makes sense to match the handling of unpaired low surrogates.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Berkeley DB license (was Re: Points of order on this WG)
On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: > I understand the interest in using Berkeley DB in browsers provided > appropriate licensing freedom were available. I am beginning to > understand your concerns vis-Γ -vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Points of order on this WG
On Friday 2009-06-26 11:27 -0700, Jonas Sicking wrote: > Note that mozilla has since long made a commitment not to ship code > that is not compatible with all of GPL, LGPL *and* MPL. So unless the > BDB license is compatible with all those three we couldn't use BDB. I think our (Mozilla's) requirement is actually slightly stronger than license compatibility, at least as defined by http://en.wikipedia.org/wiki/License_compatibility . Rather, I think we require that the licenses don't impose any restrictions in addition to those imposed by the MPL, the LGPL, or the GPL. (In other words, that the license is less restrictive than *each* of those licenses.) For what it's worth, the license document in question, located at http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html appears to suggest that the files in the source code are covered under three different licenses (although it's not entirely clear to me what is meant by the concatenation of three licenses, my initial guess is that it means different parts are covered under different licenses). The second and third given appear to me to be the three-part BSD license (varying by whether the copyright holder is the UC Regents or Harvard University). If my quick glance is correct and this is identical to the three-part BSD license, then I suspect the second and third licenses are unlikely to be a problem for Mozilla; we already include code licensed under the three-part BSD license (see http://opensource.org/licenses/bsd-license.php ). The first license, on the other hand, appears to be a modified version of the BSD license, with the third claused replaced by an entirely different one. I don't recognize this clause, and I suspect it would require legal analysis to determine whether it's less restrictive than the MPL, LGPL, and GPL. (Though the part that says "For an executable file, complete source code means the source code for all modules it contains." seems pretty restrictive to my untrained eyes.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
