Cameron McCormack's blog http://mcc.id.au mcc.id.au Mon, 01 Apr 2013 23:09:57 +0000 en-US hourly 1 http://wordpress.org/?v=3.4.1 @supports enabled by default for Firefox 22 http://mcc.id.au/blog/2013/04/supports-enabled-by-default http://mcc.id.au/blog/2013/04/supports-enabled-by-default#comments Mon, 01 Apr 2013 23:09:57 +0000 Cameron McCormack http://mcc.id.au/?p=226 The CSS Working Group is planning to publish the CSS Conditional Rules Module as a Candidate Recommendation soon. As a result, David Baron has landed a patch that enables the @supports rule and the CSS.supports() API by default for Firefox 22, which is scheduled to hit Release some time in May.

]]> http://mcc.id.au/blog/2013/04/supports-enabled-by-default/feed 2 Scoped style sheets http://mcc.id.au/blog/2013/01/scoped-style-sheets http://mcc.id.au/blog/2013/01/scoped-style-sheets#comments Tue, 15 Jan 2013 23:43:55 +0000 Cameron McCormack http://mcc.id.au/?p=175 Scoped style sheets are a feature from HTML 5 (or the HTML Standard, if you prefer) that allows the effect of a style sheet to be limited to a subtree of the document. By placing a scoped attribute on a <style> element, the style sheet applies only to elements within the subtree rooted by the parent of the <style> element.

For example, consider this document:

<!DOCTYPE html>
<title>Scoped style example</title>
<body>
  <style>
    p { font-style: italic; }
  </style>
  <p>The first paragraph.</p>
  <p>
    <style scoped>
      p { color: crimson; }
    </style>
    The second paragraph.
  </p>
</body>

It would be rendered as follows:

The first paragraph.

The second paragraph.

Rules in the style sheet only match an element if all of the elements matched by a selector are within the style scope. Thus, if the rule were instead body > p { color: crimson; }, it would not match that second paragraph.

The CSS Cascading and Inheritance Level 3 specification defines that when there are nested style scopes, rules on inner scopes override those from outer scopes, regardless of the specificity of the rules. Using !important reverses this, and allows outer scopes to win over inner scopes. Global style sheets, including <style> elements without a scoped="" attribute or those loaded using a <link> element, are treated as if they are scoped to the root element.

One use case for scoped style sheets is to isolate a set of style rules that apply to a single article or comment within a page to ensure that they cannot affect the style of other elements on the page. On a web site that aggregates articles from different authors, this could allow the designer of the overall site to know that the elements of the page outside the article itself will not be affected by the article’s styles.

Another is to be able to specify style for a given element’s pseudo-element, or only when it matches a pseudo-class, which is not possible just by using the style="" on the element or without giving the element an ID and defining the style in a global style sheet. For example if you have an element styled like this:

<p>
  ...
  <span style="text-decoration: underline;">looks like a link</span>
  ...
</p>

and you decide you want the underline to be applied only when the element is hovered, then it’s not possible to use the :hover pseudo-class within the style="" attribute. A scoped style sheet can be used:

<p>
  ...
  <span>
    <style scoped>:hover { text-decoration: underline; }</style>
    looks like a link
  </span>
  ...
</p>

Implementation

Firefox 21, currently on the Nightly channel, supports scoped style sheets now that bug 508725 has landed. This feature is not prefixed or behind a pref. The scoped="" attribute can be placed on SVG <style> elements, too.

There are two aspects of the Firefox implementation that don’t match the specification yet:

  1. The @global at-rule, to allow all elements during selector matching except for the subject to be outside the style scope, is not implemented. The name “global” doesn’t quite convey the meaning it has, and given there are no other at-rules that can be used as a prefix to a list of selectors, some other syntax might be better. (Filed as bug 830058.)
  2. Other at-rules that have global effects, including @font-face and @keyframes, are not processed at all within scoped style sheets. The HTML specification states that these should have effects limited to the style scope. (Filed as bug 830056.)

[Edited 16 January 2013 – fixed the typo pointed out by Pablo]

]]> http://mcc.id.au/blog/2013/01/scoped-style-sheets/feed 10 The paint-order property http://mcc.id.au/blog/2013/01/paint-order http://mcc.id.au/blog/2013/01/paint-order#comments Mon, 14 Jan 2013 22:29:22 +0000 Cameron McCormack http://mcc.id.au/?p=160 In SVG 1.1, every shape and text element has its components painted in the same order: fill, then stroke and finally any markers. In some situations, authors want these to be painted in a different order. The usual workaround to achieve this is to duplicate the element, and have say a stroke but no fill set on the first and vice versa on the second.

SVG 2 adds a simple property that allows the author to control the painting order of the components of a shape or text content element: the paint-order property. The initial value of the property is normal, which gets you the default, SVG 1.1 behaviour. To specify a different order, a sequence of fill, stroke and markers keywords is used. The keywords cannot be repeated, but some can be omitted, in which case all of the remaining unspecified components are painted in their default order, after the ones that were explicitly specified. For example, paint-order="stroke" is equivalent to paint-order="stroke fill markers".

Where I often want to place the stroke underneath the fill is when stroking text. The problem with placing the stroke above the fill of a text element is that the stroke straddles the boundary of the fill, half lying inside the glyphs and half outside. This results in the apparent glyph shape changing, the thicker the stroke you use.

The following example demonstrates the use of paint-order on a <text> element to produce stroked text that looks nicer:

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="200">
  <linearGradient id="g" x1="0" y1="0" x2="0" y2="1">
    <stop stop-color="#888"/>
    <stop stop-color="#ccc" offset="1"/>
  </linearGradient>
  <rect width="400" height="200" fill="url(#g)"/>
  <g fill="crimson" stroke="white" stroke-width="6" stroke-linejoin="round"
     text-anchor="middle" font-family="sans-serif" font-size="50px" font-weight="bold">
    <text x="200" y="75">stroke over</text>
    <text x="200" y="150" paint-order="stroke">stroke under</text>
  </g>
</svg>

The example would be rendered like this:

Perhaps this comparison is a bit unfair; the apparent thickness of the stroke on the element with paint-order="stroke" is half that of the text with the default paint-order since half of it is occluded by the fill. Here is what it would look like if the first text element had stroke-width="3":

It’s clearer to see here that due to the stroke paint intruding on the fill of the first text element, the red glyphs end up looking eroded, while those in the second element appear normal.

Implementation

Since bug 828805 landed yesterday, support for the paint-order property is now available in Firefox Nightly. It currently is enabled only when the svg.paint-order.enabled property is set to true, which is the default on the Firefox Nightly and Aurora channels. Once the SVG 2 specification matures further, support will be enabled across all channels.

]]> http://mcc.id.au/blog/2013/01/paint-order/feed 2 The mask-type property http://mcc.id.au/blog/2012/12/mask-type http://mcc.id.au/blog/2012/12/mask-type#comments Sat, 29 Dec 2012 02:49:08 +0000 Cameron McCormack http://mcc.id.au/?p=102 TL;DR: The mask-type property is now available in Firefox Nightly.

Here is a simple use of an SVG mask:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 512 341" width="512" height="341">
  <defs>
    <mask id="m">
      <circle cx="256" cy="200" r="150"/>
    </mask>
  </defs>
  <g mask="url(#m)">
    <image width="512" height="341.5" xlink:href="http://farm8.staticflickr.com/7063/6860283873_b9f2e6d511_b.jpg"/>
    <!-- original: http://www.flickr.com/photos/yewenyi/6860283873/
         http://creativecommons.org/licenses/by-nc/2.0/ -->
  </g>
</svg>

And here is how it renders:

Er, what? This should be a simple raster image masked by a circle. What went wrong?

If you’re like me, you would have made this mistake a thousand times. The problem is that the mask element looks at the luminance of the mask child content to determine how much of the masked graphics to let show through. Luminance is a measure of brightness – black has luminance of 0 and white has a luminance of 1. The different red, green and blue component values contribute with different weights, and the luminance value is then multiplied with the alpha of the mask content pixel to determine the final mask value. For each pixel, the mask value is multiplied by the RGBA pixel in the masked content. Since our mask consists only of a black circle (black is the initial value of the fill property), the mask value over the entire mask is 0, letting nothing of the masked content through! What we should have done is specified fill="white" on the circle.

It is a very common misconception that SVG masks look just at the alpha of the mask content, and this is also a common way that masks are used in authoring tools. To accommodate this, SVG 2 uses the new CSS Masking specification, which, among other things, allows an author to specify that the alpha of a mask’s content, and not the luminance, is used to determine mask values. This is done by the use of the mask-type property. We can use it in our example as follows:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 512 341" width="512" height="341">
  <defs>
    <mask id="m" mask-type="alpha">
      <circle cx="256" cy="200" r="150"/>
    </mask>
  </defs>
  <g mask="url(#m)">
    <image width="512" height="341.5" xlink:href="http://farm8.staticflickr.com/7063/6860283873_b9f2e6d511_b.jpg"/>
    <!-- original: http://www.flickr.com/photos/yewenyi/6860283873/
         http://creativecommons.org/licenses/by-nc/2.0/ -->
  </g>
</svg>

and the resulting image would look like this:

Now, obviously this example is simple enough that if you could remember that you needed to change something to make the mask work, you would probably remember that fill="white" would work just as well as mask-type="alpha". The mask-type property could become more useful if you already have some graphics (either SVG content, perhaps referencing some raster images too) that has alpha. Although it would be possible to use an SVG filter to convert the alpha channel into an opaque image with just the right shade of white, this seems unnecessary work for the author.

Since mask-type is a CSS property, it means you can also set it once for all masks in a document with a single style rule, mask { mask-type: alpha }.

Implementation

Bug 793617 has just landed, which means that the mask-type property is now available in Firefox. As with other new features we have been implementing recently, this property is not prefixed. Instead, it lives behind a pref – layout.css.masking.enabled in this case. The pref will default to being true for Nightly and Aurora builds, and false for Beta and Release. Once the CSS Masking specification has matured further, the feature will be enabled by default on all builds. This means that you can begin experimenting with the property, but don’t write productions web sites that rely on it just yet!

In WebKit land, Dirk Schulze has implemented the property, also without a prefix.

[Edited 29 December 2012 – fix the examples to not use fill="white" as pointed out by roc]

]]> http://mcc.id.au/blog/2012/12/mask-type/feed 4 CSS.supports() API in Firefox Nightly http://mcc.id.au/blog/2012/12/css-supports-api http://mcc.id.au/blog/2012/12/css-supports-api#comments Wed, 26 Dec 2012 23:33:29 +0000 Cameron McCormack http://mcc.id.au/?p=133 As a followup to this post announcing the @supports at-rule implementation, Firefox Nightly now (as of bug 779917) has support for the DOM API part of the CSS Conditional Rules Level 3 specification. The new CSS.supports function can be called in two different ways. The first is with a property name and value pair:

if (CSS.supports("display", "flex")) {
  // do something relying on flexbox
}

The second is with an entire expression that can appear just after @supports:

if (CSS.supports("(display: flex) and (display: grid)")) {
  // do something relying on flexbox and grid layout
}

As with the @supports rule itself, the CSS.supports() API lives behind the layout.css.supports-rule.enabled pref, which is enabled by default in Nightly and Aurora builds of Firefox.

[Edited 28 December 2012 – fixed display: flexbox to display: flex as pointed out by fantasai]

]]> http://mcc.id.au/blog/2012/12/css-supports-api/feed 0 Two new reftest features http://mcc.id.au/blog/2012/11/two-new-reftest-features http://mcc.id.au/blog/2012/11/two-new-reftest-features#comments Thu, 29 Nov 2012 01:29:17 +0000 Cameron McCormack http://mcc.id.au/?p=89 Running a subset of reftests

One aspect of running reftests that periodically annoyed me was that I would often want to run a subset of all the reftests within a particular directory. Sometimes it would be a single test that I wanted to run, other times a particular set of tests. With the mochitest harness, it’s easy to run an individual test:

$ TEST_PATH=path/to/the/test.html make -C $(OBJDIR) mochitest-plain

or just:

$ ./mach mochitest path/to/the/test.html

if you’re using mach. This wasn’t possible with the reftest harness, since you need to give a manifest file that has information about what the document that provides the reference image is, whether it’s a test for equality or inequality, and so on.

Usually I would deal with this by either writing up a new manifest file, copying the relevant entries from the real reftest.list manifest, or by temporarily commenting out all the entries but the ones I was interested in. This was a bit of pain, so now with bug 809312 landed, you can pass a --filter command line option to runreftest.py to select which tests to run.

--filter takes a regular expression against which to test the first (test) URL of each test entry in the manifest file you are using. It uses JS regular expression syntax. So if you are still using the make targets to run reftests, you could do this:

$ EXTRA_TEST_ARGS=--filter=mask TEST_PATH=layout/reftests/svg/ \
    make -C $(OBJDIR) reftest

and it will run only the reftests whose test URL matches /mask/. And with mach it’s simpler:

$ ./mach reftest layout/reftest/svg/ --filter=mask

If you just want to run a single reftest, you can write the whole filename there:

$ ./mach reftest layout/reftest/svg/ --filter=mask-basic-01.svg

It’s still a regular expression, so the dot will match any character, but it’s unlikely to matter given the simple filenames we use.

Note that the regular expression is matched against the absolute URL of the test document, which is going to be something like file:/path/to/your/repo/layout/reftests/.... So if you specify --filter=file don’t be surprised if all tests run!

Specifying default preferences in a reftest manifest

Recent features I have been working on, such as @supports, live behind a pref until we decide that their relevant specification is stable enough. We default the pref to true for Firefox Nightly and Aurora builds, and false for Beta and Release. Initially, I had a number of reftests for @supports that were skipped when the feature was not enabled, but it was pointed out that it would be better to force the pref on while running the tests so that we didn’t lose test coverage on the Beta and Release branches. My reftest manifest then looked like this:

pref(layout.css.supports-rule.enabled,true) == css-supports-001.xht support/pass.xht
pref(layout.css.supports-rule.enabled,true) == css-supports-002.xht support/pass.xht
pref(layout.css.supports-rule.enabled,true) == css-supports-003.xht support/pass.xht
pref(layout.css.supports-rule.enabled,true) == css-supports-004.xht support/pass.xht
pref(layout.css.supports-rule.enabled,true) == css-supports-005.xht support/pass.xht
...

It seemed a bit silly to have to repeat this pref() setting for each test, so with bug 788967 landed, you can now use a default-preferences statement in a reftest manifest to specify preferences to use for the remaining tests in the manifest:

default-preferences pref(layout.css.supports-rule.enabled,true)
== css-supports-001.xht support/pass.xht
== css-supports-002.xht support/pass.xht
== css-supports-003.xht support/pass.xht
== css-supports-004.xht support/pass.xht
== css-supports-005.xht support/pass.xht
...

pref(), test-pref() and ref-pref() can all be used in a default-preferences statement.

See the reftest documentation for very slightly more details.

]]> http://mcc.id.au/blog/2012/11/two-new-reftest-features/feed 1 Support for @supports in Firefox Nightly http://mcc.id.au/blog/2012/08/supports http://mcc.id.au/blog/2012/08/supports#comments Fri, 03 Aug 2012 01:25:56 +0000 Cameron McCormack http://mcc.id.au/?p=73 Yesterday I landed support for the CSS @supports at-rule for Gecko (based in part on some earlier work done by former intern Vitor Menezes), and it should now be in Firefox Nightly builds. @supports is part of CSS Conditional Rules Module Level 3, and allows authors to condition rules based on whether particular property declarations are supported.

For example, let’s say you want to use a WOFF font but only if you are able to turn on its use of tabular numerals through the ‘font-variant-numeric’ property from css3-fonts. You could write that as follows:

@font-face { font-family: MyFontWithTabularNumerals; src: url(some.woff); }

.price { font-family: monospace }

@supports (font-variant-numeric: lining-nums) {
  .price { font-family: MyFontWithTabularNumerals;
           font-variant-numeric: lining-num; }
}

The text between the @supports and the open brace is the supports condition, and the rules within the braces are only applied if the condition evaluates to true. In a user agent that supports @supports but not ‘font-variant-numeric’, elements with class “price” will be rendered with the standard monospace font, but for those that do implement the property, MyFontWithTabularNumerals will be used.

The supports condition can use conjunctions, disjunctions and negations to form an expression:

@supports (width: 75vw) and (height: 50vh) {
  #main { position: absolute; top: 32px; left: 32px;
          width: 75vw; height: 50vh; }
}

@supports not (font-size: calc(1rem + 8px)) {
  body { font-size: 16px }
  body > h1 { font-size: 24px }
}

Note that a supports condition that includes a mix of conjunctions and disjunctions must always use parentheses to explicitly indicate their precedence. For example, instead of

@supports (color: green) and
          (background-color: yellow) or
          (background-color: eggyolk) ...

you must write either:

@supports (color: green) and
          ((background-color: yellow) or
           (background-color: eggyolk)) ...

or:

@supports ((color: green) and
           (background-color: yellow)) or
          (background-color: eggyolk) ...

Support behind a pref

To avoid having to prefix @supports, the implementation lives behind a preference that for the moment is enabled. If by the time Firefox 17 gets to Beta (some time in October) we feel that the specification is not yet stable enough or there aren’t any other implementations, we’ll flip the pref back to turn it off in the Beta channel so that we have some more time to tweak the implementation before the web starts to depend on it.

In the meantime, we encourage authors to experiment with it and provide feedback!

Update: While the changes have landed in the mozilla-central repository, they arrived after today’s Nightly was built! So check back in 24 hours and then you’ll be able to try it out.

]]> http://mcc.id.au/blog/2012/08/supports/feed 17 Integrating the Self-Serve Build API with Tinderboxpushlog http://mcc.id.au/blog/2011/04/integrating-self-serve-with-tbpl http://mcc.id.au/blog/2011/04/integrating-self-serve-with-tbpl#comments Wed, 27 Apr 2011 04:28:45 +0000 Cameron McCormack http://mcc.id.au/?p=46 A couple of months ago, Chris AtLee announced the Self-Serve Build API, a RESTful HTTP interface to Mozilla’s build system that lets users kick off and cancel builds themselves. The API is exposed with a simple web interface, but more convenient would be the ability to cancel and re-run builds directly from Tinderboxpushlog. Now that bug 634915 has landed, that convenience has arrived!

To request an additional build or test run, select an already completed job and click on the “Rebuild” icon.

The "Rebuild" icon is the blue plus symbol that appears in the bottom left build information box.

You can request multiple runs just by clicking the icon multiple times in succession. There’s no need to wait for one request to have completed before clicking it again, either.

Each time the "Rebuild" icon is clicked, a status is shown at the top of the page indicating the status of the request.

To cancel a build, click on the “Cancel” icon that appears in the same place after clicking on a build that is pending or already running.

Note that bug 634592 was recently fixed, so this works for cancelling test runs as well as builds themselves.

Be patient though, after cancelling or requesting a new build. It can take a minute or two for the results to show up in the main TBPL view!

]]> http://mcc.id.au/blog/2011/04/integrating-self-serve-with-tbpl/feed 3 Across the Tasman http://mcc.id.au/blog/2010/10/across-the-tasman http://mcc.id.au/blog/2010/10/across-the-tasman#comments Sun, 24 Oct 2010 06:32:12 +0000 Cameron McCormack http://mcc.id.au/?p=35 Now that I’m getting settled in, it’s time to get blogging again. Settled in where, you say? At the start of this month, I made the cross-Tasman voyage to Auckland to start working at Mozilla! It’s an exciting change for me, and it probably wouldn’t be too much of an exaggeration to say that it’s pretty much my dream job! Who wouldn’t want to be paid for hacking on open source software? Being able to walk to work in about five minutes isn’t half bad, either.

I’m three weeks in so far, and I’ve mostly been getting back into web standards groups that I was involved in before taking my hiatus to finish off my thesis. (“How is that thesis going?” I hear you ask, as politely as you can when enquiring about such things. Well, I got a goodly amount done during that time – importantly, I finished work on the diagram authoring tool and ran the experiment – but the thesis itself isn’t done. Writing continues on weekends and other non-work time.) In that time I’ve managed to finish porting Web IDL to ECMAScript 5, which was one of the major tasks remaining to do on it, and on Thursday a new Working Draft was published. Yeah!

Hopefully my new machine arrives next week, and I can start on My First Bug™.

]]> http://mcc.id.au/blog/2010/10/across-the-tasman/feed 1 Moved http://mcc.id.au/blog/2009/03/moved http://mcc.id.au/blog/2009/03/moved#comments Mon, 02 Mar 2009 00:57:48 +0000 Cameron McCormack http://mcc.id.au/?p=28 I haven’t officially been a student since March last year, when my candidature lapsed; I’m a part-time research assistant now. Over the last 12 months I technically haven’t been allowed to stay in the shared postgrads office, but Kim somehow had managed to organise for me to stay in there on one of the free desks. Since the beginning of this year, the calls from the admin staff for me to move out have intensified, with new PhD students starting and being allocated to desks in the office. So today I have finally given in and moved two doors down to room 134 sharing with pjrm. My new number here is +61-3-9905-8673.

]]> http://mcc.id.au/blog/2009/03/moved/feed 0