The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.
The major changes in this version relate to the way searching and property-based lookup is done on characters in the lower left panel, and features for refining and capturing the resulting lists.
Removed the two Highlight selection boxes. These used to highlight characters in the lower left panel with a specific property value. The Show selection box on the left (used to be Show list) now does that job if you set the Local checkbox alongside it. (Local is the default for this feature.)
As part of that move, the former SiR (search in range) checkbox that used to be alongside Custom range has been moved below the Search for input field, and renamed to Local. If Local is checked, searching can now be done on any content in the lower left panel, and the results are shown as highlighting, rather than a new list.
To complement these new highlighting capabilities, a new feature was added. If you click on the icon next to Make list from highlights the content of the lower left panel will be replaced by a list of just those items that are currently highlighted - whether the highlighting results from a search or a property listing. Note that this can also be useful to refine searches: perform an initial search, convert the result to a list, then perform another search on that list, and so on.
Finally got around to putting icons after the pull-down lists. This means that if you want to reapply, say, a block selection after doing something else, only one click is needed (rather than having to choose another option, then choose the original option). The effect of this on the ease of use of UniView is much greater than I expected.
Added an icon to the text area. If you click on this, all the characters in the lower left panel are copied into the text area. This is very useful for capturing the result of a search, or even a whole block. Note that if a list in the lower left panel contains unassigned code points, these are not copied to the text area.
As a result of the above changes, the way Show as graphics and Show range as list work internally was essential rewritten, but users shouldn’t see the difference.
Changed the label Character area to Text area.
background-color
property
to solve ISSUE-65.
Rationale: While this makes the property slightly
harder to read and requires typing out transparent
in
full every time, it solves the 2-token lookahead problem very
simply.background-image
should
determine the number of background layers. ISSUE-74.
Rationale: Less likely to cause confusion for
authors or introduce unintended behavior through the cascade.
Pending: Since Apple has already implemented the
other option, we are waiting to hear back from them. If they agree
this issue will be resolved as above.The main change in this version is the reworking of the former Cut & paste and Code point(s) fields to make it easier to use UniView as a generalised picker.
Moved the cut&paste field downwards, made it larger, and changed the label to character area. This should make it easier to deal with text copy/cut & paste, and more obvious that that is possible with UniView. It is much clearer now that UniView provides character map/picker functionality, and not just character lookup.
Whereas previously you had to double-click to put a character in the lower left pane into the Cut&paste field, UniView now echoes characters to the Character area every time you (single) click on a character in the lower left hand pane. This can be turned off. Double-clicking will still add the codepoint of a character in the lower left panel to the Code points field.
The Character area has its own set of icons, some of which are new: ie. you can select the text, add a space, and change the font of the text in the area (as well as turn the echo on and off). I also spruced up the icons on the UI in general.
Note that on most browsers you can insert characters at the point in the Character area where you set the cursor, or you can overwrite a highlight range of characters, whereas (because of the non-standard way it handles selections and ranges) Internet Explorer will always add characters to the end of the line.
The Code points field has also been enlarged, and I moved the Show list pull-down to the left and Show as graphics and Show page as list to the right. This puts all the main commands for creating lists together on the left.
When you mouse over character in the lower left pane you now see both hex and decimal codepoint information. (Previously you just saw an unlabelled decimal number.) You will also find decimal code point values for characters displayed in the lower right panel.
Fixed a bug in the Code points input feature so that trailing spaces no longer produce errors, but also went much further than that. You can now add random text containing codepoints or most types of hex-based escaped characters to the input field, and UniView will seek them out to create the list. For example, if you paste the following into the Code points field:
the decomposition mapping is <U+CE20, U+11B8>, and not <U+110E, U+1173, U+11B8>.
the result will be:
CE20: 츠 [Hangul Syllables]
11B8: ᆸ HANGUL JONGSEONG PIEUP
110E: ᄎ HANGUL CHOSEONG CHIEUCH
1173: ᅳ HANGUL JUNGSEONG EU
11B8: ᆸ HANGUL JONGSEONG PIEUP
Of course, UniView is not able to tell that an ordinary word like ‘Abba’ is not a hex codepoint, so you obviously need to watch out for that and a few other situations, but much of the time this should make it much easier to extract codepoint information.
I still haven’t found a way to fix the display bug in Safari and Google Chrome that causes initial content in the lower left pane to be only partially displayed.
Here are some lists of characters that are useful for normalization. I’ll probably add some others later.
The lists apply to Unicode version 5.1.
The files below contain declarations for JavaScript sparse arrays. They are easy enough to convert to other formats using global search and replace. The verbose version provides character names and code points.
Characters with non-zero combining properties are assigned to a sparse array indexed by codepoint. The value gives the combining property value.
http://rishida.net/code/normalization/nonzerocombiningchars.txt
http://rishida.net/code/normalization/nonzerocombiningchars-verbose.txt
There are 498 of these.
This list maps single characters to their decompositions. The single character is referenced by an index into the array, and the value for that index is the decomposed characters.
http://rishida.net/code/normalization/canonicaldecomposables.txt
http://rishida.net/code/normalization/canonicaldecomposables-verbose.txt
There are 2042 of these characters.
The following code converts a hex codepoint to a sequence of bytes that represent the Unicode codepoint in UTF-8.
This is useful because PHP’s chr() function only works on ASCII :((.
function cp2utf8 ($hexcp) { $outputString = ''; $n = hexdec($hexcp); if ($n = 0x7F) { $outputString .= chr($n); } else if ($n = 0x7FF) { $outputString .= chr(0xC0 | (($n>>6) & 0x1F)) .chr(0x80 | ($n & 0x3F)); } else if ($n = 0xFFFF) { $outputString .= chr(0xE0 | (($n>>12) & 0x0F)) .chr(0x80 | (($n>>6) & 0x3F)) .chr(0x80 | ($n & 0x3F)); } else if ($n = 0x10FFFF) { $outputString .= chr(0xF0 | (($n>>18) & 0x07)) .chr(0x80 | (($n>>12) & 0x3F)).chr(0x80 | (($n>>6) & 0x3F)) .chr(0x80 | ($n & 0x3F)); } else { $outputString .= 'Error: ' + $n +' not recognised!'; } return $outputString; }
Six Revisions put six questions to the estimable Eric Meyer on the subject of CSS3, and we get some nice link love.
Also (and I’m slightly late with this one) John Resig, creator of the jQuery library, runs an approving eye over the Advanced Layout Module. Webmonkey provide further context. We looked at the module back in 2006 (part one, part two), and my tongue-in-cheek prediction of a ten year wait to use it is now down to only eight years…
Opera have announced the first Alpha release of the next version of their browser. Codename Peregrine features version 2.2 of their Presto rendering engine, which boasts 100% Acid 3 compliance, a 30% speed boost on certain sites, and a number of new features for web developers.
As CSS enthusiasts it’s the latter we’re interested in, of course, and the notable CSS3 implementations are:
For those of you not on the www-style mailing list, you may not
be aware that Dean Jackson announced
today that Apple have published updated proposals for
Transitions, Animations and Transforms. This news comes after
the recent decision by the CSSWG at their October F2F meeting that
it
is very likely that the CSSWG will accept to work on them [Apple's
proposals]
.
Full details of what’s been changed in these updated proposals
can be found in Deans
email, however, the
most significant changes are splitting 2D and 3D transforms into
separate documents and adding a list of properties that can be
animated (and how to interpolate different property types)
It’s worth noting that these documents are only proposals, are likely to change, and haven’t formally been accepted by the W3C.
There’s been an apparent need (voiced by the web community) for CSS-based Constants ever since the conception of CSS (even though there are many established server-side preprocessors in existance). From reading blogs and the like, people are either very much in favour or very much against the idea, but the feature’s mixed reception hasn’t stopped members of the CSSWG exploring and discussing the idea further, to the point where we now have two fairly detailed proposals from members of the Working Group. The aim of this post is to explore and then summarise the current state of both proposals (from an authors not a vendors point of view), comparing features of both.
Back in March this year, Dave Hyatt and Daniel Glazman combined forces and presented the first formal proposal for Variables to the Working Group, and (based on this spec) Hyatt subsequently implemented the module into Webkit nightlies; the implementation was distributed for around 5 months, but was later removed due to concerns regarding feature adoption by authors before the spec had any time to mature. In August this year, fantasai submitted a counter-proposal which detailed plans for a parse-time syntax for Constants (which are lost after the variables are parsed and therefore not mutable), compared to Hyatt’s/Glazman’s proposal which allowed for scriptable Variables.
Fantasai’s proposal features three types of named Constants,
‘values’, ’style-sets’ and ’selectors’; a value constant
represents a property value, a style-set constant
represents one or more property declarations and a selector
constant represents a selector. Each are declared using an
@define
rule and as fantasai explains, the syntax
of an
. Examples (ripped straight from her proposal :)) showing
the syntax for each of the three Constants are below:-@define
rule is the @define
at-keyword, followed by either the values
keyword (for
declaring value constants) or the style-sets
keyword
(for declaring style-set constants) or the selectors
keyword (for declaring selector constants), followed by a
block
@define values { textColor: black; bgColor: white;
accentColor: silver; accentBorder: double silver 5px; }
define style-sets { noteBox { border-style: solid;
padding: 1em; border-radius: 1em; } quoteBox { margin: 1em; }
}
A feature of fantasai’s proposal is that constants are re-usable, so you can include ’style-set templates’ which can be applied to multiple selector declarations, using different value constant values.
Note that any selectors used in such a variable aren’t allowed to be grouped (using the comma-seperated grouping syntax), since we will have the ability to group selector variables anyway. Selector constants would be useful for repeatedly selecting child/grandchild etc elements deep within a complex DOM tree; consider this:-
@define selectors { deeplynestedelement: body.home
> div#main.container ~ ul#navigation > li
a[href="http"] span#child >
span#imrunningoutofnames;}
deeplynestedelement u, deeplynested b{ color:red;
}
And with the addition of a possible :match()
pseudo
class in Selectors Level 4, you could do something like this to
make the above statement even more organised:-
deeplynestedelement:matches(u,b){ color:red; }
Instead Hyatt’s/Glazman’s proposal simply utilises a new
@variables
rule in which any type of variable
(presumably) can be used, without the need for type keywords -
their proposal isn’t actually clear on whether different types of
variables can be parsed (or whether this proposal simply targets
value constants), however, after looking at several
test cases, the implementation seems like it was capable of at
least parsing ’style-sets’ constants too.
@variables { CorporateLogoBGColor: #fe8d12; }
div.logoContainer { background-color:
var(CorporateLogoBGColor); }
Two fairly major differences between the two proposals are their
scoping behaviour. In fantasai’s proposal, by default, the scope
of a named constant does not ordinarily cross @import
boundaries
; this essentially means that the use of variables
declared in one @import
are restricted to that
particular stylesheet, unlike Hyatt’s/Glazman’s proposal where, by
default, constants cross @import
boundaries. However,
using fantasai’s proposal, authors do have complete control over
the scope by using one of three new keywords (which is placed
between the @import
keyword and the stylesheet URI),
push
, pull
and sync
;
pull
allows constants declared within the imported
stylesheet to be used in the importing stylesheet;
push
allows constants declared above the
@import
rule in the importing style sheet to be used
the imported style sheet; sync
allows both of the
previous, simultaneously.
The two proposals differ also in the way that constants relate
to, and work with Media Types. In
Hyatt’s/Glazman’s proposal, an optional Media Type keyword can be
placed between the @variables
keyword and succeeding
block declaration. In fantasais proposal, constant declarations
(placed within a @define
block) can be nested within
an @media
block. However she metions, …if declared
inside an
, meaning that
constants can be used outside of the @media
rule, the scope of the declaration
does not end with the @media
block@media
they’re
placed in. It’s worth mentioning that the @media
rule
model/syntax differences could be trivially modified to use the
other’s media type syntax.
From the October F2F
CSS Working Group minutes (Apple’s proposal); Apple
presented their proposals for Animations and Transitions, made
remarks on Transforms, gradients, reflections. All four major
browser vendors are interested in these proposals, and it is very
likely that the CSSWG will accept to work on them.
Exciting
stuff!
Hakon presented a proposal for a border-parts
property, which defines an on/off mask over the border as a
series of lengths
; you can check out his proposal in more
detail on www-style.
Note, this is still very much an unapproved proposal and the WG
have stated that they are still unsure how usable/useful a solution
such as this would be.
Dave Hyatt and Daniel Glazman initially came up with a proposal for CSS Variables, and fantasai has now created a counter-proposal detailing plans for a purely parse-time, non-scriptable solution. To help distinguish between the merits of both, I’ve come up with a brief article comparing and summarising both proposals.
page
should be a
non-inherited property. auto
means look to the nearest
non-auto
ancestor and use that page
value. Implementations that do inherit 'page' will be considered
conformant to CSS3 Paged Media (since that is the
currently-specified behavior), but not CSS4 Paged Media. We will
add warning authors that the behavior of 'page: auto' would be
unpredictable when used within an element with 'page:
somethingelse'.Discussed overflow of multicolumn elements: whether new columns should be madd off to the side, or whether a new row of columns should be created as overflow below.
To create a layouts where a new set of columns are created below the first, we really would need a column-length property or somesuch and allow the height to be auto, otherwise the new columns will overflow the multicol element and overwrite later content.
Either way, multicolumn layout is not very usable on the screen
because it's designed for paginated media. So we discussed the idea
of overflow-style: paginate
to create paginated
layouts on the screen. (It would fall back to scrolling behavior on
down-level clients.)
fantasai noted that the column width algorithm should define available width such that the UA can consider the available width on the page if that is less than the available width of the element.
:hover
to apply to an element because its
child is designated by a pointing device, then it's possible for
:hover
to apply to an element that is not underneath
the pointing device. Rationale: The spec leaves
undefined whether the :hover
state is passed up the
DOM tree. Browsers all treat it that way and websites would break
if that were changed. We're adding this note to clarify to readers
that it :hover
can match an element even if it not
hovered over if its child is positioned outside its geometric
bounds.:active
, but made no
resolutions about it.an+b
grammar in ISSUE-66 to the
Selectors spec.The portion of a child element that occurs on the first line inherits properties applicable to the ::first-line pseudo element; for properties not applicable to the ::first-line pseudo element, the inheritence is from the non-pseudo-element parent of the ::first-line pseudo element. The portion of a child element that does not occur on the first line always inherits from the parent of that child.
Discussed F2F meetings for next year, settled on three 3-day meetings:
Discussed lack of web designers on CSSWG and what to do about it. Neither Molly nor Jason (AOL) could make it to this F2F, and AOL is withdrawing from W3C. The CSSWG wants to keep Jason as an Invited Expert, but this is generally inconsistent with W3C policy and would require an exception from W3C management. Also discussed other possibilities (unminuted).
Apple presented their proposals for Animations and Transitions, made remarks on Transforms, gradients, reflections. All four major browser vendors are interested in these proposals, and it is very likely that the CSSWG will accept to work on them. Apple says they are willing to drive the specs, but the CSSWG chairs remind them that they need to show up and participate in the group discussions.
Briefly discussed interaction of Apple's proposals with SVG.
Regardless any progress on these is on hold until the rechartering process is complete.
There was some discussion of the GCPM drafts and which parts of it could move forward. No resolutions.
Spent some time explaining to the IBM accessibility guy that
David Baron will be clarifying the spec to make this clear.
Discussed two-token lookahead problem caused by the new fallback color syntax. No resolutions.
fantasai had an action item from the last F2F to draw up a parse-time constants counter-proposal to CSS Variables. This was completed and presented.
Håkon presented a proposal for a border-parts
property, which defines an on/off mask over the border as a series
of lengths. There was lots of discussion about syntax, and lots of
skepticism about its usability and utility.
I have just upgraded the Malayalam picker to level 7, and added a bunch of new features that should show up in other pickers at level 7 as I get time:
Shape view The pickers are aimed particularly at people who are not familiar enough with a script to use the keyboard. However, there are many ligatures and conjuncts in Malayalam, which makes it difficult to identify the character sequences needed. This view provides most of the shapes you’ll see in Malayalam text, grouped by shape. It’s something I’ve been wanting to add to the pickers for some time.
Phonic view This has been done in other pickers, but it has some new features over those. The sounds have been arranged along similar lines to a standard IPA chart, and multiple transcriptions are supported. In addition, you can click on the transcription text to build up a phonemic string in IPA. This is particularly useful for creating examples.
Regular expressions in searches The search feature was upgraded to allow for regular expressions. So now you can highlight characters containing GA without highlighting ones containing NGA: just search for \bga\b (or use the convenient short-cut form .ga.). Of course you can do more complicated searches too.
Add codepoint You can add a hex codepoint value to the box in the yellow area to insert into the text. This is useful for things like the odd unusual character, or for just figuring out what a sequence of codepoints represents. You can input any number of codepoints (including surrogates) into the input box, separating them by spaces.
Chillus This version of the picker supports all Unicode 5.1 characters, including the chillu characters. Because most Malayalam fonts support the old way of inputting chillu forms, you can specify in the yellow box area what you want the output to be when clicking on a chillu letter: the pre-5.1 sequence or the new atomic character. (The default is the atomic character.)
The picker also comes with the usual set of level 7 features, such as font grid view, graphic characters, hiding of uncommon characters, optimised ordering of characters in the alphabetic view, two-tone highlighting, etc.
You can start up directly in either of the available views by
appending the following to your URI: ?view=
, followed
by one of, respectively, alphabet
, shape
,
phonic
or fontgrid
.
Enjoy.
A large amount of code was rewritten to enable data to be downloaded from the server via AJAX at the point of need. This eliminates the long wait when you start to use UniView without the database information in your cache. This means that there is a slightly longer delay when you view a new block, but the code is designed so that if you have already downloaded data, you don’t have to retrieve it again from the server.
The search mechanism was also rewritten. The regular expressions used must now be supported in both JavaScript and PHP (PHP is used if not searching within the current range). When ‘other’ is ticked, the search will look in the alternative name fields, but not in other property settings (so you can no longer use something like ;AL; to search for characters with a particular property. (Use ‘Show list’ instead.))
Removed several zero-width space characters from the code, which means that UniView now works with Google Chrome, except for some annoying display bugs that I’m not sure how to fix - for example, the first time you try to display any block you only seem to get the top line (although, if you click or drag the mouse, the block is actually there). This seems to be WebKit related, since it happens in Safari, too.
Please report any bugs to me, and don’t forget to refresh any UniView files in your cache before using the new version.
An advantage of not posting for a while is that there are usually plenty of good subjects to talk about when you get back to it…
With a kind nod of the head to our post from way back in 2006, Andy Clarke has posted a screencast (with full transcript and code examples) of RGBa values in action on his website For A Beautiful Web.
Over at Javascript Kit they’ve produced an exhaustively in-depth look at structural pseudo-classes.
On the subject of Javascript, Eric Meyer has written about how it can be leveraged to extend CSS3 support across browsers.
And Helen from Helephant.com writes a good introduction to the box-sizing property.
Note that the 'direction' property is often set by rules in the UA style sheet based on mark-up in the document, as recommended in CSS 2.1 [CSS21] section 9.10 ("Text direction: the 'direction' and 'unicode-bidi' properties").
When formatting content in the page model, some content may end up outside the current page box. For example, an element whose 'white-space' property has the value 'pre' may generate a box that is wider than the page box. As another example, when boxes are positioned absolutely or relatively, they may end up in "inconvenient" locations. For example, images may be placed on the edge of the page box or 100,000 meters below the page box.
I finally got to the point, after many long early morning hours, where I felt I could remove the ‘Draft’ from the heading of my Myanmar (Burmese) script notes.
This page is the result of my explorations into how the Myanmar script is used for the Burmese language in the context of the Unicode Myanmar block. It takes into account the significant changes introduced in Unicode version 5.1 in April of this year.
Btw, if you have JavaScript running you can get a list of characters in the examples by mousing over them. If you don’t have JS, you can link to the same information.
There’s also a PDF version, if you don’t want to install the (free) fonts pointed to for the examples.
Here is a summary of the script:
Spaces are used to separate phrases, rather than words. Words can be separated with ZWSP to allow for easy wrapping of text.
Words are composed of syllables. These start with an consonant or initial vowel. An initial consonant may be followed by a medial consonant, which adds the sound j or w. After the vowel, a syllable may end with a nasalisation of the vowel or an unreleased glottal stop, though these final sounds can be represented by various different consonant symbols.
At the end of a syllable a final consonant usually has an ‘asat’ sign above it, to show that there is no inherent vowel.
In multisyllabic words derived from an Indian language such as Pali, where two consonants occur internally with no intervening vowel, the consonants tend to be stacked vertically, and the asat sign is not used.
Text runs from left to right.
There are a set of Myanmar numerals, which are used just like Latin digits.
So, what next. I’m quite keen to get to Mongolian. That looks really complicated. But I’ve been telling myself for a while that I ought to look at Malayalam or Tamil, so I think I’ll try Malayalam.
I have just upgraded the Burmese picker as follows:
Rearranged characters The Myanmar3 font expects multiple combining characters to be entered in the order described in the Unicode 5.1 Standard for correct display. The panel of combining characters has been arranged so that you can easily remember what that order was. Characters to the left precede those to the right, characters higher up precede those lower down.
In addition to that, I have rearranged all the character positions so that it is easier to locate the various parts of a syllable as you type.
I also added some combinations of characters that make up multi-part vowels and the kinzi with a single click.
I have also moved some of the less common characters to an ‘advanced’ area to the right which can be opened and closed by clicking on the arrow-head icon.
New highlighting As you mouse over a character the picker will show you other characters that are visually similar (particularly useful for those not very familiar with the script). This new version shows the more likely confusable characters with a blue outline, and other similar characters with orange. This is useful given that many Myanmar characters look quite similar.
As always, you can turn off this feature or disable it in the URI you use to call the picker.
Font grid view Shows characters in Unicode order, using whatever font is specified in the Font list or Custom font input fields. This allows comparison of fonts (especially useful in IE, which shows if a glyph is missing from a font).
You can start up directly in either of the available views by
appending the following to your URI: ?view=
, followed
by one of, respectively, alphabet
or
fontgrid
.
Enjoy.
Mozilla employee John Daggett has provided some
try‐out builds of Firefox with support for the
@font-face
from CSS3’s web-fonts module. Currently
available for Windows and Mac only—no Linux build yet—there remain
several caveats as described in his comment on bug 70132, the
most important of which being that the same‐site origin restriction
is turned on by default, which means that most examples on the web
will not work until you turn it off.
We've published a new official Working Draft of the CSS Backgrounds and Borders Module Level 3. Some major changes from the last draft include:
border-radius
background-position
syntax for positioning offsets from
corners other than the top leftbackground-clip
cover
and contain
values for background-size
that proportionally stretch the background image to either cover or
be contained by the entire background areabackground
shorthandCheck it out and send us some feedback. This draft is in the stabilizing phase: the next publication should be the last one before Candidate Rec, and we'd rather get your comments this round. The plan is to do some more polish work, respond to comments and suggestions, and then publish a Last Call with this feature set near the end of the year.
This information was released today on the Working Group blog and there looks to be some major updates.
border-radius
has been updated so that you can now specify different irregular
curves on an element - this was a well-known abiguity that Peter
pointed out in the former Working Draft.inset
keyword.background-color
value syntax which
means fallback colours can be specifiedno-clip
value for
background-clip
background-size
values
(cover
and contain
; they both scale the
image whislt retaining its intrinsic aspect ratio. The difference
however, is that by using the cover
keyword value, the
image scales to the largest size such that both its width and its height can completely cover the background positioning areato. Whereas
scale
scales the image to the largest size such that both its width and its height can fit inside the background positioning area.
background
shorthand
propertyI’ll try and clarify some of these updates when I get some more time. All in all, some great new updates, though!
If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.