To coincide with Web 2.0 Expo in New York, Opera is organising a free Standards.Next event on the topic of CSS3 the following Friday 20th November, at the Time–Life Building. This space has been generously donated to us by Time & Life.
The Standards.Next concept is to showcase, teach and raise awareness of future Web standards-based technologies. After two events in London featuring HTML5 and Accessibility, our third event is the first time we’ve brought the event State side. With NYC being a design-centric town, CSS3 was the perfect topic.
Mozilla has joined a growing list of organizations to throw their support behind the Web Open Font Format (WOFF) and will support the embedding of WOFF fonts via @font-face from Firefox 3.6 onwards, or if you’re a developer and want to play around with this now, just download a recent nightly build or beta.
The CSS Working Group just published a Last Call for Comments Working Draft of CSS Backgrounds and Borders Level 3. Please review the draft and send your feedback. We’ll be accepting comments through 17 November 2009. (Note that feature requests are likely to be deferred to CSS4.) The best place for feedback is the CSSWG’s official mailing list [email protected], but we’ll also look at any comments posted (or linked to) here on CSS3.info.
There are a couple issues we’re specifically looking for feedback on:
Rounding vs. Scaling Down
border-image-repeatresizes images to fit the nearest whole number of tiles, rather than always scaling up or always scaling down. Rounding keeps closer to the intended size and, in the case where one dimension is fixed (e.g. in ‘border-image’), keeps the image closer to the intended aspect ratio. This is almost certainly the best solution for vector images and high-resolution raster images. However, if the given image is a low-resolution raster image, it will require interpolating pixels, which can look bad. See Rounding Extremes for illustrations.
The workaround is to specify a higher-resolution image (e.g. by shrinking from the original with
border-image-width). Possible spec solutions include introducing a separate keyword that always scales down, and changing the algorithm so that we force scaling down whenever interpolation would be required for scaling up. So the options here are
- Leave the spec as-is (always round to nearest): the workaround is good enough for me.
- Trigger forced downscaling when interpolation is needed: avoiding interpolation is important to me and I don’t mind that the exact number of tiles is unpredictable and the resulting aspect ratio might skewed a little extra.
- Default to rounding for
round, but I want an extra keyword to force downscaling in all cases (including vector images) because […].
- Something else?
Please comment on what you prefer and why. (The more specific you can be “for example, this image that I would want to use […]”, the easier it will be for us to understand your point.)
The previous draft included two properties for controlling behavior at box breaks (line breaks / column breaks / page breaks):
border-breakfor controlling whether the border is drawn at the break, and
background-breakfor controlling whether the background is drawn for each box individually or for the whole element as if it were broken after painting.
Hyatt suggested merging the two, so the current draft has a single
box-breakproperty instead. The two values mean, basically, “render backgrounds and borders for this box, and then slice it up” and “break the box and then render backgrounds and borders for each box individually”. The value names aren’t particularly clear, however, so we were wondering if anyone has better ideas.
So take a look at the new draft and send us your comments! This is your last chance to give feedback on this module: if all goes well, we’ll be publishing the Candidate Recommendation in time for Christmas, and given the state of experimental implementations right now, I expect things to move rapidly from there.
One of the requests that came in during the WASP feedback discussions was for image “sprites”: for the ability to take a slice of an image and use it, e.g., as a background image. This would allow lots of decorative graphics to be placed in the same file. Image slices like this are actually on the CSS Working Group’s radar; the idea’s been floating around for quite awhile, and we’ve added a placeholder for them in the new CSS3 Image Values draft.
So I wanted to gather some feedback on what syntax would be most useful to you. :) The restriction is: the syntax must be usable as a value for any property that takes images. That is, you can’t suggest new properties. It has to be something that can be used as the value for any of
border-image, etc. Bonus points for explaining why your proposed syntax is more convenient than any others.
A few ideas to start (feel free to add your opinion on these):
image-slice("image.png", X, Y, W, H)Advantage: dead simple.
url("image.png#xywh=X,Y,W,H")Advantage: can be used other places like
<img src="...">, browser address bar, etc.
Microsoft announced on Tuesday that network managers can now upgrade any Windows PC’s on their networks to the latest version of Internet Explorer 8 via their Windows Server Update Services platform, clearly representing a significant time saver for managers of large networks.
Does this easier to upgrade option mean that large organisations, businesses, schools, universities, colleges, etc., IE6’s last remaining stronghold, will now finally be encouraged to make the move away from IE6?
The CSS 3 news never really gets too quiet out there, I think that more coders and designers than ever have their heads down and hands dirty in CSS 3. How do I know? Well more tutorials and examples are being made all the time and more and more mentions are popping up on the various design and development blogs. Are your hands dirty enough? I know mine weren’t so I set out to see what’s new in for this summer as it draws to a close.
The W3C have released an updated working draft of the CSSOM View Module, edited by Anne van Kesteren.
Many of the features defined in the CSSOM View Module have been supported by most browsers for a long period of time, with many tracing their routes back to Microsoft’s Internet Explorer. The goal of this specification is therefore not to reinvent the wheel, but rather to define these features in such a way that they can be implemented by all browsers in an identical way.