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 change in this update is the update of the data to support Unicode version 6.1.0, which should be released today. (See the list of links to new Unicode blocks below.)
There are also a number of feature and bug related changes.
What UniView does: Look up and see characters (using graphics or fonts) and property information, view whole character blocks or custom ranges, select characters to paste into your document, paste in and discover unknown characters, search for characters, do hex/dec/ncr conversions, highlight character types, etc. etc. Supports Unicode 6.0 and written with Web Standards to work on a variety of browsers. No need to install anything.
List of changes:
One significant change enables you to display information in a
separate window, rather than overwriting the information currently
displayed. This can be done by typing/pasting/dragging a set of
characters or character code values into the new Popout area and selecting the 
icon
alongside the Characters or Copy & paste input fields (depending on what you
put in the popout window).
Two new icons were added to the Copy & paste area:
Clicking on this will display the characters in the area in the
lower right part of the page with all relevant characters converted
to uppercase, lowercase and titlecase. Characters that had no case
conversion information are also listed.
Clicking on this produces the same kind of output as clicking on
the icon just above, but shows the mappings for those characters
that have been changed, eg. e→E.
Where character information displayed in the lower right panel has a case or decomposition mapping, UniView now displays the characters involved, rather than just giving the hex value(s), eg. Uppercase mapping: 0043 C. You will need a font on your system to see the characters displayed in this way, but whether or not you have a font, this provides a quick and easy way to copy the case-changed character (rather than having to copy the hex value and convert it first).
There is also a new line, slightly further down, when UniView is in graphic mode. This line starts with ‘As text:’, and shows the character using whatever default font you have on your system. Of course, if you don’t have a font that includes that character you won’t see it. This has been added to make it easier to copy and paste a character into text.
There is also a new line, slightly further down, when UniView is in graphic mode. This line starts with ‘As text:’, and shows the character using whatever default font you have on your system. Of course, if you don’t have a font that includes that character you won’t see it. This has been added to make it easier to copy and paste a character into text.
Fixed some small bugs, such as problems with search when U+29DC INCOMPLETE INFINITY is returned.
Enjoy.
Here are direct links to the new blocks added to Unicode 6.1:
W3C and La Cantine invite the Web community of Paris (France) to the third W3C Meetup at La Cantine. The theme this time is CSS. The event will be held the evening of February 8, with participation of several members of the CSS working group. There will be presentations & demos in both English and French. Discussions can be in both languages; Daniel Glazman will translate between the two.
The program includes presentations by Daniel Glazman (Disruptive Innovations, co-chair of the CSS WG), Vincent Hardy (Adobe) and David Baron (Mozilla). Entrance is free, but registration is required.
The address of La Cantine is 151 rue Montmartre, 75002 Paris, between the metro stops Grands Boulevards (lines 8 & 9) and Bourse (line 3). The time on Wednesday February 8 is from 19:00 to 21:00.
currentColor
keyword, which computes on the element specified and then inherits,
instead of inheriting as a keyword and then recomputing on each
element. This is okay for non-inheriting properties like
border-color, but doesn’t work for properties that
inherit, like
text-emphasis-color. (It effectively defaults the
property to the color of the root element.) Tab to
investigate whether SVG depends on this behavior or if we can
change it.The CSS WG has published a Last Call Working Draft of the CSS3 Image Values and Replaced Content. This module covers:
element()
notation for using an elements’ graphical representation as an
image.object-fit
and object-position
for controlling aspect ratio preservation.image-resolution
for using explicit or intrinsic image resolutions.image-orientation
to correct mis-rotated images.Note that replaced elements in CSS includes not just bitmap images, but also SVG (external or embedded), video, applets, plugins, and other “foreign” objects.
There have been significant changes to gradients over the past year.
If you have comments on any part of the draft, please, send them
to the (archived)
www-style@w3.org mailing list. Start a new thread for each
issue, and include [css3-images] in the subject line.
This will help us track your comments. (And please, if you
can’t/won’t post to www-style, email the editors instead of posting
randomly into the ether.)
We welcome editorial suggestions, additional examples, diagrams, or anything else that will help to make the spec more understandable.
The official deadline for comments is 7 February 2012. Let us know if you need an extension so that we don’t miss your comments.
text-overflow:ellipsis outlined in Tantek’s
email!important
in animations rules – it’s a syntax error.!important
rules to override animations (exact location of animations in the
cascade level still undetermined)Tab Atkins and I published an updated Working Draft of CSS Image Values and Replaced Content Level 3 this month. We anticipate that this will be the last draft before Last Call, which we aim to publish in January. If you have an interest in this draft, please review it and send in your comments.
Below is a summary of the major changes to CSS gradients over the past year:
linear-gradient() changed from polar
angles to bearing angles (compass directions). 0° now points up
(bottom-to-top), and angles increase clockwise. See Angles in Gradients
for the feedback that informed this decision.linear-gradient() changed
from bare directional keywords (top,
right, bottom, left)
indicating the starting point to to <keywords>
where the keyword indicates the endpoint. (to bottom,
to left, to bottom, to
left). This change was made because Tab felt having
0deg mean bottom-to-top made the fact that
top meant top-to-bottom confusing. The WG was split
but mostly ambivalent on whether this was necessary, or whether
from <keyword> was a better alternative; the
resolution landed on to <keyword>.linear-gradient() has been
redefined so that instead of aligning the gradient line to the
diagonal, the central color occupies the other diagonal. See
Behnam
Esfabad’s post for a demonstration showing the old and new
(“magic”) versions.radial-gradient() has been changed to
(roughly)
radial-gradient( [ <shape> || <size> ] [ at
<position> ]?, <color-stop> [ , <color-stop>
]+): specifically, the shape/size and position
parameters are collapsed into the first argument using CSS property
value conventions, allowing either or both to be specified.
Position is distinguished from size by the preceding
at keyword. See Radial Gradient
Readability for some of the thinking that went into this
change.Although CSS gradients are undoubtedly the most anticipated feature in CSS3 Images, there are a number of other features in this draft:
image()
notation, which can be used in place of url(),
allows authors to trigger CSS parser fallback in older UAs when
using media fragments.image()
notation allows specifying a list of fallback images in various
formats and allows annotating images with left-to-right or
right-to-left directionality so that they flip automatically to
match the element’s directionality.object-fit
property allows preserving the aspect ratio of an image when
assigning its box a specified size. In conjunction with the
min/max-width/height properties, it also allows
scaling the image and its box up to a given maximum, or down to a
given minimum. The object-position
property allows repositioning the image within its content box
using background-positioning sytax when object-fit
causes the aspect ratio of the image and the content box to
mismatch.image-resolution
property allows for using bitmap resolutions other than 1 image
pixel == 1 CSS px unit.As always, send feedback to www-style with
the spec code ([css3-images]) and your comment topic
in the subject line. While posting to www-style is preferred, I’ve
also cross-posted to
CSS3.info, and we’ll be scanning the comments there for issues,
too.
appearance property dropped from CSS3 UIpointer-events or how to
keep it without destabilizing CSS3 UIThese are notes on using CSS @font-face to gain finer control over the fonts applied to characters in particular Unicode ranges of your text, without resorting to additional markup. Possibilities and problems.
Most non-English fonts mix glyphs from different writing systems. Usually the font contains glyphs for Latin characters plus a non-Latin script, for example English+Japanese, or English+Thai, etc.
Normally the font designer will take care to harmonise the Latin script glyphs with the non-Latin, but there may be cases where you want to change the design of the glyphs for, say, and embedded script without adding markup to your page.
For example, if I apply the MS-Mincho font to some content in Japanese with embedded Latin text I’m likely to see the following:
Let’s suppose I’d like the English text to appear in a different, proportionally-spaced font. I could put markup around the English and set a class on the markup to apply the font I want, but this is very time consuming and bloats your code.
An alternative is to use @font-face. Here is an example:
@font-face {
font-family: myJapanesefont;
src: local(MS-Mincho);
}
@font-face {
font-family: myJapanesefont;
src: local(Gentium);
unicode-range: U+41-5A, U+61-7A, U+C0-FF;
}
p {
font-family: myJapanesefont;
}
The result would be:
The first font-face declaration associates the MS-Mincho font with the name ‘myJapanesefont’. The second font-face declaration associates the Baskerville font with the Unicode code points in the Latin-1 letter range (of course, you can extend this if you use Latin characters outside that range and they are covered by the font).
When specifying src the local() keyword indicates that font-face should look for the font on the user’s system. Of course, to improve interoperability, you may want to specify a number of alternatives here, or a downloadable WOFF font. The most interoperable value to use for local() is the Postscript name of the font. (On the Mac open Font Book, select the font, and choose Preview > Show Font Information to find this.)
Note how I was careful to set the unicode-range values to exclude punctuation (such as the exclamation mark) that would be used by (and harmonised with) the Japanese characters.
You can use the same approach for fonts that don’t have support for a particular Unicode range.
For example, the Nafees Nastaliq font has no glyphs for the Latin range (other than digits), so the browser falls back to the system default.
With the following code, I can produce a more pleasant font for the ‘W3C’ part:
@font-face {;
font-family: myUrduFont;
src: local(NafeesNastaleeq);
}
@font-face {
font-family: myUrduFont;
src: local(BookAntiqua);
unicode-range: U+30-FF;
}
div p {
font-family: myUrduFont;
font-size: 60px;
}
If you look at the ranges in the unicode-range value, you’ll see that I kept to just the letters of the alphabet in the Japanese example, and the missing glyphs in the Urdu case.
There are a number of characters that are used by all scripts, however, and these cause problems because you can’t apply fonts based on the context – even if you could work out what that context was.
In the case of the Japanese example above, numbers are left to be rendered by the Mincho font, but when those characters appear in the Latin text, they look incorrectly sized. Look, for example, at the 3 in W3C below.
The same problem arises with spaces and punctuation marks. The exclamation mark was left in the Mincho font in the Japanese example because, in this case, it is part of the Japanese text. Punctuation of this kind, could however be associated with the Latin text. See the question mark in this example.
Even more problematic are the spaces in that example. They are too wide in the Latin text. In Urdu text we have the opposite problem, use Urdu space glyphs in Latin text and you don’t see them at all (there should be a gap between W3C and i18n below).
With my W3C hat on, I start wondering whether there are any rules we can use to apply different glyphs for some characters depending on the script context in which they are used, but then I realise that this is going to bring in all the problems we already have for bidi text when dealing with punctuation or spaces between flows of text in different scripts. I’m not sure it’s a tractable problem without resorting to markup to delimit the boundaries. But then, of course, we end up right back where we started.
So it seems, disappointingly, that the unicode-range property is destined to be of only limited usefulness for me. That’s a real shame.
The examples don’t show major problems, but I assume that sometimes the fonts you want to bring together using font-face will have very different aspect ratios, so you may need to use something like font-size-adjust to balance the size of the fonts being used.
The CSS code above worked for me in Chrome and Safari on Mac OS X 10.6. but didn’t work in Firefox or Opera. Nor did it work in IE9 on Windows7.
Last week the CSSWG published updates to four layout-related CSS specs:
[css3-flexbox])[css3-layout])chains property
to combine multiple slots in a template into a single one, in order
to create areas with complex and disjoint shapes; and a larger
number of properties that apply to slots: the style of a slot in
turn influences the style of the elements placed inside it
(region-based styling).[css3-regions])[css3-gcpm])Template Layout relates closely to Grid Layout, Flexbox, and Regions; however, these high-level layout modules have yet to be fully integrated.
As always, send feedback to www-style with
the spec code ([css3-flexbox],
[css3-regions], [css3-layout], or
[css3-gcpm]) and your comment topic in the subject
line.
There appears to be some confusion about XHTML1.0 vs XHTML5. Here is my best shot at an explanation of what XHTML5 is.
application/xhtml+xml). See
examples and more explanations.XHTML5 is an HTML5 document served as*
application/xhtml+xml (or another XML mime type). The
syntax rules for XHTML5 documents are simply those rules given by
the XML specification.
The vocabulary (elements and attributes) is defined by the HTML5 spec.
Anything served as text/html is not XHTML5.
Note that HTML5 (without the X) can be written in a style that
looks like XML syntax. For example, using a / in empty elements
(eg. <img src="..." />), or using quotes around
attributes. But code written this way is still HTML5, not XHTML5,
if it is served as text/html.
There are normally other differences between HTML5 and XHTML5. For example, XHTML5 documents may have an XML declaration at the start of the document. HTML5 documents cannot have that. XHTML5 documents are likely to have a more complicated doctype (to facilitate XML processing). And XHTML5 documents will have an xmlns attribute on the html tag. There are a few other HTML5 features that are not compatible with XML, and must be avoided.
Similar differences existed between HTML 4.01 and XHTML 1.0.
However, moving on from XHTML 1.0 will typically involve a subtle
but significant shift in thinking. You might have written XHTML 1.0
with no intention of serving it as anything other than
text/html. XHTML in the XHTML 1.0 sense tended to be
seen largely as a difference in syntax; it was originally designed
to be served as XML, but (with some customisations to suit HTML
documents) could be, and usually was, served with an HTML mime
type. XHTML in the XHTML5 sense, means HTML5 documents served with
an XML mime type (and appropriate customisations to suit XML
documents), ie. it’s the MIME type, not the syntax, that makes it
XHTML.
Which brings us to Polyglot documents. A polyglot document is a
document that is the subset of HTML5 and XML that can be processed
as either HTML or XHTML, and can be served as either
text/html or application/xhtml+xml, ie.
as either HTML5 or XHTML5, without any errors or warnings in either
case. The polyglot
spec defines the things which allow this compatibility (such as
using no XML declaration, proper casing of element names, etc.),
and which things to avoid. It also mandates at least one additional
extra, ie. disallowing UTF-16 encoded documents.
radial-gradient( [
<shape> || <size> ]? [at <position> ]?, ...
)voice-durationmin() and
max() from Values and Units Level 3 to Level 4@keyframes@font-face will be
same-origin by default with the use of CORS to relax for HTTPflex-order takesflex-order, not flex-index.min-width; min-content is not an implied
minimum.flex-align:
stretch, honor max-width, then
start-align.visibility:
collapse.break-before:column
won’t force a blank column when the element is the first in the
column.page-break-before/after
doesn’t create a break if you’re at the top of the page, where at
the top of the page means no content has been placed. Borders do
not count as content. Zero-height elements count as content.John Daggett summarized what Unicode is doing with UTR 50, which will define the default orientation of each character in vertical text. Those interested are encouraged to review the draft and send Unicode comments: Unicode Technical Report #50
Rossen presented the current Exclusions and Shapes draft. Two major concerns were raised:
Resolved: Publish FPWD of Exclusions
Minutes and Resolutions TPAC 2011-10-30 Sunday Afternoon II: Style Attr, Selectors 4, Paginated Layout on Screen
Daniel raised some concern that web designers are assuming everything in Selectors 4 will make it to CR, even though it’s a very early stage draft and we don’t know what will make it and what not. (The ability to select ancestors of elements is a particular area of concern since it is difficult to optimize for CSS selection in dynamic environments.)
Håkon presented a demo
of a new paginated layout feature in Opera: it uses the
overflow properties to switch the UA into a paginated
mode. The demo also included some new features for UI to link
independent documents together into a single paged
presentation.
The Future of Style features:
CSS WG Blog CSS3 . Info Speaking in styles W3C i18n and css W3C's Cascading Style Sheets home
page ishida blog » cssIf 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.
