- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 31 Aug 2010 06:59:27 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Testing and PR
--------------
jdaggett takes Microsoft's marketing dept. to task for publishing
PR articles using test results from unreviewed Microsoft tests
"that wouldn't even pass Microsoft's internal review" while implying
that they were accepted by W3C. Advice for the future includes:
- giving some kind of notification about the tests and the
intent to publish test results
- using only reviewed tests for marketing purposes
- just generally making a good faith effort when publishing
test results
Fonts
-----
jdaggett reviewed the font-variant-* features. Comments included:
- font-variant-ligatures should note that it doesn't affect
required ligatures
- Many members of the WG are (still) concerned about the use of
numeric alternate glyph selection in 'font-variant-alternates'
in a way that does not tie the numbers to specific fonts, the
problem being that the numbered options would be applied to
fallback fonts, resulting in unexpected glyph selections.
jdaggett protested that this isn't a problem in reality
Adobe asserted that it will become more and more of a problem
over time as use of advanced font technology increases.
Several alternatives were proposed:
- Allowing numeric glyph selection only via @font-face
- Using a functional notation to tie that selection to a
specific font family
- Using an at-rule to match named identifiers to pairs of
numeric selections and font-family names. (This has the
added benefit of giving the author an obvious way to
note what such numbers mean to any future maintainers.)
- Suggestion to have petite-caps fall back to small-caps.
jdaggett to mark this in the spec as an issue.
- Discussed jdaggett's proposal to CSSify font-feature-settings
syntax by using idents and functional notation in place of
strings. Bert noted that this may conflict with things like
attr(), so the WG suggested prefixing each value with ot-.
Also discussed error-handling.
- Noted that font-language-override's values are OT lang codes,
not ISO lang codes. One suggestion was to accept ISO lang
codes as idents and OT lang codes as strings.
- RESOLVED: Publish new css3-fonts WD
- Some discussion about font family names inside fonts and how
to make use of them across platforms.
Writing Modes
-------------
- Discussed various solutions for dealing with vertical writing
modes and the resulting directional transformations.
- Several strongly against :ttb solution, since it is supposedly
a pseudo-class, but is selecting a property of the UA, not of
the element. Media Queries are seen as a more appropriate
place to detect features of the UA environment.
- The WG favors alternate style sheets for writing mode switching,
since they give the most versatile solution. Some guidelines
are needed to allow standardized tagging of alternate styles.
But once those are in place, EPUB can choose what switches it
needs, similar to defining a microformat.
- Some comments made about detecting vertical writing support, but
nothing definite.
- Some discussion of the cascading problems with margin-start/end.
And also the similar but somewhat different case of
margin-outside/inside, whose directions must be computed as
pages are laid out and cannot be resolved during the cascade.
- RERESOLVED: Physical directions stay physical: margin-left will
always refer to the left side, not the top or right side based
on physical directions.
#rrggbbaa
---------
- RESOLVED: Add #rrggbbaa to css4-color
CSS3 UI and UI Selectors
------------------------
Tantek is going through the CR and will be re-issuing an LC which:
- removes all unimplemented features
- adds related features that have two+ implementations, e.g.
- pointer-events
- overflow-x/overflow-y
There was a suggestion to extract the selectors in this draft into
a standalone UI Selectors module.
dbaron wrote a list of 5 requirements for ::selection:
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
WG agrees with all of them; it's now a matter of defining a model
that accommodates all of them.
i18n: list-styles and Indic layout
----------------------------------
http://lists.w3.org/Archives/Public/www-style/2010May/0328.html
Authors can already map list styles to languages with :lang(),
so this feature does not seem necessary. However, the WG would
consider adding the feature described if someone else did the
necessary research to draw up an exhaustive table mapping lang
codes to list-style-types and the i18nWG approved it, since most
of the difficulty in the feature is in drawing up that table
correctly.
A new group at W3C is planning to draw up requirements for Indic
layout, similar to the JLTF efforts.
CSS Template Layout
-------------------
Discussed Hyatt's proposal to alter syntax to make prefixing
easier (which has the side effect of making the style sheet
easier to understand, especially for someone unfamiliar with
the Template module):
http://lists.w3.org/Archives/Public/www-style/2009Mar/0191.html
The WG votes to add slot() notation to the 'position' values
and to wrap the template strings in functional notation rather
than add a new property as in Hyatt's proposal.
CSS3 Values and Units and calc()
--------------------------------
Proposed to move css3-values to CR, starting by trimming any
unfinished features and drawing up an at-risk list in prepartion
for LC. This would mean:
- dropping fr and gr, since they aren't standalone units anyway
- Marking vh, vw, vm, and min() and max() at-risk.
====== Full minutes below ======
Present:
César Acebal
David Baron
Bert Bos
Tantek Çelik
John Daggett
Arron Eicholz
Elika Etemad
Daniel Glazman
John Jansen
Håkon Wium Lie
Chris Lilley
Alex Mogilevsky
David Singer
Steve Zilles
Partial (late afternoon via phone + IRC):
Sylvain Galineau
Additional Topics
-----------------
tantek: I'd like to talk about CSS3 UI again.
dbaron: Vendor prefixes and whether we can remove it for calc().
fantasai: CSS 2.1 margin collapsing.
jdaggett: Test submission
arronei: CSS 2.1 dates
Tests and PR
------------
ScribeNick: fantasai
<jdaggett>
http://blogs.msdn.com/b/ie/archive/2010/08/04/html5-modernized-fourth-ie9-platform-preview-available-for-developers.aspx
jdaggett: This is a blog post by the IE team, by Dean, talking about
the platform preview.
jdaggett: There's a section where he's talking about tests, specifically
this paragraph "With Platform Preview 4, we're contributing
... standards bodies..."
jdaggett: He's got this list that's implying that IE9 is the most
compatible browsers
jdaggett: The number of tests listed -- this is a really bad statement.
jdaggett: They were not submitted tests.
jdaggett: And the tests wouldn't ebven pass review at Microsoft
jdaggett: It's always good that have tests that pass in other browsers
jdaggett: but I think this just represents a bad faith effort on the
part of the marketing dept at MS
jdaggett: This is just irresponsible.
jdaggett: If they want to say "we have this set of tests, and we pass,
and they don't"
jdaggett: that's fine, but to imply that they have been blessed by
the standards group
dbaron: If you're going to publish them this publicly, you should be
more responsible about responding to error reports
glazou: When IE9 published a set of tests, there were 11 Selectors tests
and 3-4 (?) were wrong
glazou: And these tests were showing overwhelmingly better support in IE9
glazou: But because of these errors, it was actually the other way around
JohnJansen: There is a level of clarification that would make this better
JohnJansen: First, we're not unresponsive.
dbaron: When the blog post is getting a lot of PR, it's not getting a
lot of PR a week later when you fix the tests.
JohnJansen: I don't believe it's intentionally a bad faith efford.
I think it's an error.
jdaggett: I understand that marketing wants to go out and say "we're the best"
jdaggett: Other people in the org should say, that's a fine thing to
say, but you shouldn't say it in this way.
jdaggett: This is flagrantly inaccurate
jdaggett: tests were checked in, but no notice that they were submitted
anne: What John is saying that you haven't emailed public-css-testsuite
with notice about the tests
anne: You've only checked them in. Nobody knows they're there
* fantasai notes they were also in the incoming folder, which is considered
scratchspace, not a submission
jdaggett: I don't want to have a nitpicky about what rule was or was
not followed
jdaggett: I'm just saying that this is bad faith effort. Someone is
trying to insinuate that these are official standards-body-blessed
tests.
jdaggett: If you look at some of these tests, the quality is not there.
These should have been reviewed before posting.
JohnJansen: You're saying that we shouldn't submit tests that wouldn't
pass our internal review process. I agree with you.
JohnJansen: But also the prose here is missing the clarification that
the tests were not submitted.
dbaron: I don't want to see you block your submissions due to not
having completed your internal review
dbaron: But don't publicize those tests.
dsinger: Publishing numbers on the other browsers before they've had a
chance to run it is not very good
jdaggett: I think we all can sit down and write tests that will fail
in other browsers. It's an exercise we can do.
jdaggett: But it doesn't help us as a group trying to promote CSS
jdaggett: Authors will think, oh, this feature is not stable, I cannot
use this feature.
JohnJansen: I don't think these tests are intended to fail in other
browsers -- they're just trying to test the features.
dsinger: we really do appreciate these tests
Tantek: I'd like to emphasize dbaron's point.
Tantek: The earlier and more open the review, the better.
Tantek: The key is not to connect that with some kind of summary result
JohnJansen: Until they're reviewed.
Tantek: Having everyone able to review the tests is great. I'm a fan of
the open review.
Tantek: There were two problems: The first one was the lack of notification.
The second was publishing results on unreviewed tests.
jdaggett: Another problem is some of the tests will only work on Windows
because of specific font dependencies
jdaggett: For a test that's a general browser tests, it has to be a
different test.
jdaggett: I don't want to say you need to do specifically X, Y, and Z,
but I want you to make a good faith effort.
Fonts
-----
jdaggett: I wanted to talk about font features, review where we are,
what's been fixed up, and then where we're going from here
ChrisL: It might be useful to note that this part of the spec was
reviewed at TypeCon last week
jdaggett: Right.
jdaggett: Just to step back and review what we're talking about,
we're extending font-variant to support OpenType features.
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-rend-props
jdaggett: By that I mean many are features that are general to font
formats, but we're looking at OpenType features especially
jdaggett: OpenType features affect not font selection, but glyph
selection and position
jdaggett: It's sort of about layout, but in the context of text
layout within a line
jdaggett: The idea is to extend font-variant
jdaggett: There's a whole list of these features. Some of these are
only used by a shaping engine when rendering a particular
language, etc.
jdaggett: The question is how dow we reduce the stress of creating
new properties
jdaggett: We want to group these into logical sets of properties
jdaggett: As I said, it's about OpenType primarily -- we've given a
mapping from these features to these OpenType features.
jdaggett: That way implementations know exactly what to do
jdaggett: For other font formats, it's not normatively defined, but
you can use the OpenType mapping to determine what the
correct behavior would be.
jdaggett: For different scripts, the font will enable different features.
jdaggett: Fonts have default glyphs for each codepoint.
jdaggett: In general, the author can choose a special glyph,
otherwise we use the default glyph
jdaggett: There are some features that are font-specific. E.g. you
give it a number and it picks that glyph set
jdaggett: People have brought up the issue that they don't want
fallback to bring in unintended alternates, so I've
tweaked the spec to address that.
jdaggett: Another commment is that OpenType allows both script-specific
and language-specific features.
jdaggett: The script is inferred from the codepoints
jdaggett: The language is given by the 'lang' attribute.
jdaggett: first part here is kerning
jdaggett: I originally had this as none or normal
jdaggett: But the WebKit guys didn't want to have kerning on by default,
so we added an 'auto' value
jdaggett: Leaving it up to the UA whether to enable kerning or not
jdaggett: The feature allows authors to ensure kerning is on
howcome: Are there any other controls we should add here?
jdaggett: There was some confusion from the type community was they
thought 'auto' meant optical kerning.
howcome: We could add an 'optical' keyword later
ChrisL: jdaggett explained what 'auto' means in CSS, and it was ok
jdaggett: font-variant-ligatures
Steve: 'normal' here seems to mean something different
jdaggett: In OpenType there are specific sets of features that are
commonly enabled.
jdaggett: others are not
jdaggett: For example, common ligatures are typically enabled,
and discretionary ligatures are not
jdaggett: by default
jdaggett: That's the default of the OpenType engine
Steve: So you're using 'normal' for the OpenType default
ChrisL asks about Arabic ligatures
jdaggett: We don't allow access to controlling required ligatures
(those needed to display the language correctly) through
this property
<ChrisL> jdaggett mentioned adding text to say that hinting auto
does not mean 'autohinting' in the typographic sense.
That would be a useful addition
several discuss having a 'none' value
jdaggett thinks it's not necessary, not useful, and potentially
confusing since it doesn't address required ligatures
Steve: sounds like the spec should say that this property doesn't
influence required ligatures
Steve: It would be useful to note in the definition that required
litagatures are not affected by this property
jdaggett: font-variant-alternates
jdaggett: You can set e.g. swash forms through this
jdaggett: And a font can have multiple swash sets, so it takes a number
jdaggett: There are no names for swash sets, you use numbers, e.g. swash(3)
jdaggett: So the numbers here are not selecting specific glyphs,
but a set of glyphs identified in the font
jdaggett: A font can have a set of variations
jdaggett: In the case of character variants, you can pick specific
variants for a particular glyph
jdaggett: E.g. people researching old Greek coins
jdaggett: can express exactly what was on the coins
<jdaggett> http://typography.com/fonts/font_documentation.php?docID=6&productLineID=100026#sets
jdaggett: This is a font by ? and Frere Jones
jdaggett: They did the Gotham font Obama used in his campaign
jdaggett: They're a very smart set of people, and they have brilliant
documentation
jdaggett: They show the number, and then what it means
jdaggett: You can mix and match these
jdaggett: MS has provided support for style sets in Office 2010,
but you can't select multiple sets
jdaggett: (except with Visual Basic)
Steve suggests having an at-rule to assign names to the numbers
jdaggett wants to hold off until later and stabilize the spec
jdaggett: Let's talk about fallback
jdaggett: Anything with a number is labeled as "font-specific"
<ChrisL> this feature helps keep the info in the style, rather than
being in markup (or worse, images) to get this effect
jdaggett: They do not apply to generic font families or to the UA's
ultimate fallback font
dsinger: suggests s/given font-family list/specified font-family list/
fantasai: I don't think this is really disconnecting the style set
numbers from inappropriate fonts
fantasai: ... [gives some examples of fallback fonts that are not the
generic or UA default: e.g.
- mixing fonts to get more script coverage
- listing many similar fonts to pick up one that's installed
on the system
- user stylesheet applies a different font than the author
specified
]
ChrisL: If you as a reader want to reset the font-family, you can
also reset font-variant.
howcome: I think it should only apply to the first font in the
font-family list
jdaggett doesn't agree
someone brings up selecting multipe fonts from different families
to support multipe scripts
steve: Why didn't you allow assigning a family name along with the number?
jdaggett: what if you want the number to apply to all the fonts in your list?
dsinger and stevez suggest that it would be better to connect to
the family name because there are cases where the style set
numbers don't match across fonts that you selected, and you
know it already
<dsinger> well, it might be, especially if I am aware that two different
platforms are likely to end up using two different fonts, and
the variants I need in those fonts are differently numbered
steve: I accept that it's useful to have some kind of convenient way
to trigger stylistic variations, and requiring the use of a
separate font for each one is a burden
steve: but the third point is that I'm not convinced this gives enough
power to make it worthwhile
steve: The issues about how fallback is handled become sufficiently
complex that I'd almost rather you not do anything and have us
come up with a better solution later
steve: This solution doesn't give me enough power to get consistent results
steve: Because there are enough ....
dsinger: How consitently is the same feature labeled across fonts?
<dsinger> apparently, the answer is not very
dbaron: the point is that 99% of the fonts don't have these features,
so the most common case will be a single downloadable font at
the start of the font list being the only one that has these
features
fantasai: But the use of advanced OpenType features is increasing over
time, and default fonts shipped with the OS are likewise
increasing in quality.
steve: The case that I'm concerned about is that Apple will ship a
font with stylistic variants on their platform
steve: And Microsoft will do the same. They won't be the same font.
They won't have the same stylistic numbers. And I will need
to put both fonts in my list to get the local one that ships
Steve: I see that as being almost 100% certain
dbaron: In that case you can use @font-face with src: local
dbaron: You can have an @font-face with ArialFunnyK and HelveticalFunnyK
and use those
steve: You're assuming in this design that there aren't going to be
fonts with different stylistic variants in the same font-family list
steve: And I think you're completely wrong, I think that it's almost 100%
certain that we'll get that case
Tantek: I have a dumb question. Was it considered to use strings
instead of numbers in the fonts?
jdaggett: The font format has a way of assigning names to these.
jdaggett: But most fonts don't use them.
jdaggett: Secondly, those names are localized. So what exactly are
you matching against?
jdaggett: The only reliable identifier is the number.
Tantek: I'm concerned about the readability and maintainability of
style sheets with these arbitrary numbers
ChrisL proposes syntax to map a keyword name to a number and a font
ChrisL: have an @-rule that defines names for the swash numbers for
a given family
ChrisL: So you can define "swishes" for font X to be 3, and "swishes"
for font Y to be 1
dsinger: How would I naively expect to be able to do this?
dsinger describes use case that's solved by @font-face
Tantek: Have you talked with the TypeKit folks?
Steve: Adobe's customers want to use the Web.
licensing discussion
* dbaron thought we had this exact same discussion a few meetings back
fantasai: I still have strong concerns about the way numbers aren't
tied to a specific font.
fantasai: I understand that you want a quick way for authors to
enable features
fantasai: I'd be satisfied if the numbers were only assigned to the
first font in the list, to limit damge from font fallback
fantasai: I'm also happy with the solution proposed by ChrisL, or
the earlier one to specify a family name with the number.
dsinger: I can't imagine someone caring enough about fonts to select
these specific features that wouldn't want to use an @font-face
rule to get it exactly right.
<tantek> I tend to agree with dsinger.
steve: I agree with dsinger
<tantek> @font-face is the right place for this level of detail for fonts.
jdaggett: you keep talking about finding a more ideal way of doing this, ...
steve: we've already had two suggestions, Arron's to pair the number
with a font-family name
steve: And Chris's to map numbers to names in a 3-way table
steve: These are both better ways of handling it than what you've got
jdaggett: font-variant-small-caps?
jdaggett: Simulation only for small-caps
jdaggett: Some people asked about all-small-caps and all-petite-caps
and why not use small-caps + text-transform
jdaggett: The reason is that there are other glyphs that might be
altered when the font designer knows they will be all
small-caps, e.g. adjusting punctuation and currency signs
fantasai: There was a suggestion that petite-caps should fall back to
small-caps.
jdaggett: use a font that has petite-caps
fantasai: What if I don't care too much about what font is being used
so I don't bother to give you a downloadable font
fantasai: But I prefer petite-caps to small-caps, but small-caps is
closer to what I want than lowercase letters.
Tantek: How do I ask for petite-caps without naming a font?
Tantek: The Web is becoming more and more diverse wrt devices. You
have less control about what font is being used
* dsinger example of small and petite here:
http://www.aimwell.org/Fonts/fonts.html (about half-way
down, by 'Garava')
jdaggett doesn't think this is a real problem because platform fonts
don't have petite-caps
* fantasai doesn't understand this argument
<fantasai> platform fonts are becoming more and more sophisticated over time
steve asks for fallback on style selection, e.g.
font-variant-caps: petite-caps, small-caps
Tantek: Say someone comes out with this ebook reader with a handful of
super-amazing fonts
Tantek: as an author, I don't know the font names, because it hasn't
been released yet
Tantek: but I want to use the features in these fonts.
...
<ChrisL> http://typekit.com/fonts/p22-underground-petite-caps
Bert gives an example of where petite-caps -> small-caps is important:
Bert: say I want my heading names in petite caps. If you fall back
to regular lowercase, then there is nothing to distinguish
my headings from paragraph text.
Bert: I would rather fall back to small-caps, so the distinction
between headings and paragraph text is still there.
fantasai: small-caps is more similar to the intended effect
Steve: there are two ways to do fallbacks: one is hardwired, e.g.
small-caps gets synthesized
Steve: the other is to have the author specify a fallback
...
fantasai: nobody is arguing for synthesized petite-caps. We're
suggesting it falls back to small-caps
ACTION: jdaggett Add this as an issue to the spec.
<trackbot> Created ACTION-262
jdaggett: vertical-position .. not settled on the name --
superscripts/subscripts
03:50 -!- lstorset [lstorset@213.236.208.22] has joined #css
jdaggett: We'd talked about the interaction between vertical-align
and this feature.
jdaggett: I haven't put Steve's proposal is in the spec yet
jdaggett: Type community also has trouble with the way this is
handled in fonts, because if the glyphs are not available
it's not clear what to do
jdaggett: If you specify font-variant in an @font-face rule, that
establishes the default.
fantasai: What happens if I assign the variantified font to a
paragraph, and then assign font-variant: initial to it?
jdaggett: That resets the font to the OpenType defaults
fantasai: How do you distinguish that case (setting font-variant
explicitly to its initial value) from not setting
font-variant on the paragraph?
jdaggett: Ah. Let's mark that as an issue.
fantasai: If you want to have a value that resets font-variant,
you need a new value that explicitly does that, since
the default behavior is to preserve font-specific settings.
jdaggett: Low-level feature settings
jdaggett: Right now the spec is defined as taking a string, which
is a set of name-value pairs
jdaggett: This gives you very low-level control.
jdaggett: It gives people using unusual features the ability to
trigger them.
jdaggett: Users can do stupid things with this, but it's an escape
mechanism so that you can access all the features of
the font system.
jdaggett gives an example of the syntax
jdaggett: I posted a new proposal that removes the stringiness of
the proposal
jdaggett: My proposal is to simply give a list of idents, ident(<integer>)
jdaggett: where itent without the parens essentially implies ident(1)
jdaggett: A problem with that is that opentype feature names can
e.g. start with a number, and idents can't do this
jdaggett: but in practice nobody do this
Bert: You can escape the number, then it's ok
jdaggett: One problem with this is that it's very OpenType specific
jdaggett: This syntax works well for OpenType
jdaggett: maybe not for other font systems
jdaggett: e.g. AAT uses long arbitrary strings
jdaggett: Graphite uses numeric identifiers
Steve: An implementor could map OpenType features to features in other fonts
jdaggett: Jonathan Kew mentioned that this new syntax makes it very
opentype-specific
Bert: A note about syntax, if you have a functional notation name it
could conflict with CSS functional notation names like attr() or rgba()
ChrisL: You could do ot-FUNC()
ChrisL: That deals with the OpenType-specificness by making it explicit
<Bert> (ot-hwid(1), or ot(hwid, 1)?)
<fantasai> former, I think :)
dbaron asks about error handling
dbaron: If I have a functional notation with two arguments, does that
cause the entire declaration to be dropped, or do I just
ignore that one thing
<fantasai> e.g. font-feature-settings: ot-hwid(1) gr-width(halfwidth, 1);
jdaggett prefers dropping the entire declaration
jdaggett reviews the "Rendering considerations" section, which defines
which feature settings override which other ones
jdaggett shows an example of @font-face that sets oldstyle-nums
proportional-nums and a styleset, which is used for the body.
Another rule assigns tabular-nums for tables.
jdaggett shows an example where font-feature-settings is used to obliquify
only the latin text, not the cjk characters
jdaggett shows an example of font-feature-settings overriding
font-variant-ligatures, even though the font-variant-ligatures
rule is more specific -- because font-feature-settings always
overrides
jdaggett: this is an example of something being used in an un-CSS-like way
* dbaron reminds ChrisL that it's a bug in the spec that it's using CSS
for content rather than for presentation
jdaggett: OpenType allows you to have language-specific features
jdaggett: Some common ones are within Cyrillic, Bulgarian, Macedonian,
and ? have their own glyphs for certain codepoints
jdaggett: OpenType allows you to use the same font across languages,
and just tweak the font glyph selection to pick the right
font for that language.
jdaggett: In general, you want to render in the content language
jdaggett: But in some cases, you want an override. This property is
here to allow that.
jdaggett shows an example where the content language is automatically
used to select the appropriate font features (this is the
default behavior)
dsinger: This is OpenType specific codes
ChrisL: SVG does the same thing
dsinger: But these aren't the ISO codes
<dbaron> http://www.loc.gov/standards/iso639-2/php/code_list.php is
the ISO 3166 codes
jdaggett: You could define a mapping from ISO lang codes to OpenType codes
jdaggett: But there are some cases where there isn't a mapping
e.g. having modern and classical typographic styles
for a particular language
dsinger: What if you want to use an SVG font? That would want an ISO
code, right
<dbaron> 'There are 21 languages that have alternative codes for
bibliographic or terminology purposes. In those cases, each
is listed separately and they are designated as "B"
(bibliographic) or "T" (terminology). '
<Bert> (Make it ugly? ot-SRB, ot("SRB"))
fantasai: I understand why using OpenType lang codes makes sense here
fantasai: But maybe have two ways of indicating the language --
fantasai: use an identifier or a string, where the identifier is
assumed to be an ISO lang code that you have to map
fantasai: to the OpenType code
fantasai: (which you have to be able to do anyway, for the lang attribute)
fantasai: and if it's a string, take it as an OpenType code
howcome: Why do we set the language here in CSS?
jdaggett: It's an override. You should be using the content language
in most cases (set by the lang attribute)
jdaggett: But in some cases you do need an override, because you want
to render something that is in one language (and correctly
tagged as so) using the typographic conventions of another
language
fantasai: I think you've done a very good job of explaining to us why
'font-language-override' is in the spec and what it should
be used for
fantasai: But none of this explanation is in the spec.
fantasai: I think 'font-language-override' should give explanations of
why it exists, and what it should be used for and also what
it should not be used for
fantasai: so I think you should add more of what you've been explaining
to us into the spec
RESOLVED: Publish css3-fonts WD
<br type="lunch"/>
ScribeNick: TabAtkins
CSS3 Writing Modes
------------------
<jdaggett> http://dev.w3.org/csswg/css3-text-layout/
jdaggett: There was significant hubbub a few months ago about proposals
for adding logical properties.
fantasai: We decided in a previous meeting that top/bottom/etc should
be absolute.
fantasai: So as soon as you write a page with lr switching or vertical
text, everything breaks.
jdaggett: So that's a compat problem with older user agent that don't
suport vertical writing.
fantasai: Another problem is that some documents that, for example,
epub wants to publish, they want to allow the user to swap
between vert and horiz text.
fantasai: Which, without logical properties, you have to write two
separate stylesheets. Or rather, about 1.5, to deal with
all the properties that are physical based.
[gap in minutes due to internet dropping for a sec]
fantasai: So it makes translating to those languages particular difficult,
because it's not just about translating, you have to deal
with the template and stylesheet.
fantasai: Also, UA stylesheet needs a margin for lists to account
for bullets - ltr lists need it on the left side, rtl lists
need it on the right side.
jdaggett: So there are defaults on particular elements that are
writing-mode dependent.
fantasai: Right, and similar for a vertical-text list.
fantasai: Your page shouln't break because you used the default layout
for a vertical page.
fantasai: So there are many cases where if you had logical properties
you could get pretty far.
fantasai: There are some things you'd want to tweak still, but most
things would translate over fine and prevent the page from
just utterly breaking when you go horiz to vert.
jdaggett: I think that when you have images as part of your layout,
those images aren't flipped, so your layout is going to
have to change; it'll be affected in a non-directional way.
jdaggett: Images aren't rotated, other content is, and that might not work.
fantasai: Right. This won't solve all problems.
howcome: We stand in a situation of independent properties to hundreds,
plus a bunch of property values.
<fantasai> I'll note that images in the content (as opposed to in the
styling) won't be rotated
jdaggett: And what about like, B&B having to go back and change?
fantasai: What exists won't change; we'd add new properties or values
to future specs.
howcome: You'd have to cascade and inherit every new property.
alexmog: You don't need to. At cascade time you know the writing-mode,
so you can just send down the correct value.
fantasai: We don't have time to go into deep details about all this right now.
jdaggett: I'll assert that I think this whole thing is a rathole,
and not really solving a larger set of problems with vertical text.
fantasai: I don't dispute that it doesn't solve all problems.
I explained the proposal, as requested. We can talk about why
the proposal exists, but we don't have time for precise details
right now.
fantasai: What the WG needs to discuss is if this is a direction we do
or don't want to explore.
szilles: I like that suggestion for discussion. Murakami-san listed 6
proposals for handling vertical text. I'd like to see which
of those we want to pursue and see the details of, and which
we can eliminate right now.
szilles: The second nice thing that could and did come out would be to
collect the requirements we're trying to satisfy.
jdaggett: To me it seems like, if you're talking about epub, this proposal
has a particular set of good and bad. But in HTML it's got
a *different* set of good and bad.
jdaggett: Like what about form controls? Does it make sense to have
vertical form controls?
fantasai: That's a different issue; it's unrelated to our proposals.
szilles: That's something that anyone who does vertical text has to
deal with, but it's not affected by how you specify it.
jdaggett: If form controls change, then it's a lot easier to talk about
this. But if some change and some don't, it's a lot more
difficult. For example, do pulldown menus rotate?
jdaggett: This is going to have a big impact, and I think we need to
avoid jumping directly into this.
fantasai: Whether form elements rotate isn't something we're going to
decide here. It's a UI designer issue.
fantasai: We're going to do vertical text; that's not a question.
I don't understand how whether form controls rotate or not
is a useful solution.
szilles: So it's a requirement for proposals to work with.
anne5: Sizing and dimensions of form controls is a real interop problem.
Someone has to answer this.
* myakura has been wondering whether the proposal can interact with CSSOM
<anne5> myakura, hey, don't make my life more complicated ;p
<Bert> http://nadita.com/murakami/epub-css/
<howcome> http://nadita.com/murakami/epub-css/
<szilles> http://nadita.com/murakami/epub-css/
[looking at the page]
fantasai: Look at the Requirements section. It givs you a rough
idea of what you're needing.
szilles: Let's take one of the other examples; a stylesheet choice
whether the page is vert or horiz.
Bert: Right, so how do we ignore what it not meant for horizontal.
fantasai: I want to get everyone on the same page for what the
problem we're trying to solve here.
<Ms2ger> Hear, hear
szilles: Ebooks will be posted to the web.
szilles: So there is a real legacy problem.
szilles: the legacy problem isn't legacy content, it's legacy UAs
annevk5: You can have a media query for a vertical-capable UA.
szilles: That isn't an overall solution - pages are often mixed vert
and horiz.
[hakon is pionting to the examples now]
howcome: the first example is two completely separate stylesheets.
howcome: the UA has to magically select the right one
howcome: Perhaps a rel attribute to help select it automatically.
Alex: this wouldn't work in IE6, which supports vertical but not
alternate style sheets
Steve: that wouldn't handle mixed vertical-horizonal text
howcome: You would have a horizontal-only stylesheet, and then
one that has complex
howcome: let's go through quickly to get an overview
howcome scrolls to pseudo class selectors
howcome: Second proposal is to use pseudoclasses.
howcome: So if you have :ltr here it means that horiz is supported
and @dir=ltr.
howcome: Same with :rtl. :ttb means vert is supported and writing-mode:tb-rl
szilles: And if it changes you're back to the same problem.
howcome: If it changes you reflow.
<anne5> (why is the initial value tb-rl?)
fantasai: The confusing thing is that :rtl :ltr are selecting against
individual elements. :ttb is selecting a user agent property
instead.
fantasai: There are better ways to do this.
TabAtkins: :ltr and :rtl behave a certain way
TabAtkins: :ttb is a completely different thing.
TabAtkins: :ltr and :rtl is determined by which direction the element is in
TabAtkins: :ttb is asking whether the UA is in vertical mode
[four conversations at once]
<anne5> (why can't :ttb be based on the computed value of 'writing-mode'
for the given element?)
<fantasai> anne5: :ttb { writing-mode: horizontal; }
<anne5> we already have that problem elsewhere
<fantasai> anne5: It's a fundamental principle that we do not make
selectors depend on the value of CSS properties
<anne5> I don't think it's a problem
<fantasai> anne5: we're not going there
<anne5> e.g. :hover { display:none }
<anne5> we already did
howcome: Next example! This is a media-query variant that
queries @media (vertical-text) {}
jdaggett: So this is asking for capability or setting?
szilles: Capability.
dbaron: You could have media queries for capability and mode separately.
howcome: where mode is whether the user has put it into vertical mode
howcome: You could also have both media queries for device capability
of doing vertical writing, and whether the user has asked
for vertical or horiz writing.
jdaggett: [shows off an ereader app with a vertical - horizontal mode
switch button]
jdaggett: It's this functionality the epub guys are talking about.
jdaggett: This seems like a red herring. There's some text you'll
look at one way, and some text you'll look at another way.
anne5: It seems weird to explicitly address this use-case. It feels
like it should be alternate stylesheets. There could be tons
of devices with weird buttons that switch things.
<dbaron> The query for capability could be @supports ( writing-mode: tb-rl )
arronei: Those devices could be designed to toggle between very
specific types of stylesheets. Maybe a rel value or similar.
szilles: Getting back to fantasai's point, I'd like to use most of my
stylesheet in either mode.
arronei: That's how alternate stylesheets work. You can set a persistent
stylesheet and then choose the particular alternates.
<anne5> there's a whole lot of style sheet types:
http://dev.w3.org/csswg/cssom/#style-sheet-collections
jdaggett: Also, that's a rare use-case. The common case is that
people are designing a page for one direction only.
<anne5> people who wrote HTML4 made this complicated
<anne5> (and also Hixie)
szilles: You're assuming that one person is doing all this.
TabAtkins: If you're now saying that pages aren't generally designing
for both directions, but you just showed off a device that
makes switching between directions easily, it feels contradictory.
jdaggett: Those are basically for compatibility. Some pages are meant
to be read horizontally or are easier to read like that,
others are easier to read vertically. The buttons aren't
really meant for user preference, just selecting the
particular mode that a certain page is designed towards.
dbaron: I don't think we should screw up vertical text on the web by
fixing it towards epub immediately. And I don't think we
*can* do it right without implementation experience.
dbaron: It's about finding the biggest use-cases first and then
figuring out the rest based on what people say they want.
jdaggett: [shows off a japanese website]
jdaggett: They're using in various places a mixture of vert and horiz text.
jdaggett: More than "how is someone doing fallback", they'll probably
design their site so that in older UAs they'll do a flash
version, and everywhere else they'll do it in CSS.
howcome: It'll probably be useful there to have a query to ask if
there is vertical support.
<jdaggett> http://www.ukai.co.jp/toriyama/flash/index.html
anne5: I don't think we necessarily have to do that. They'll find
some way to do it. We give them vertical text and they'll
play with it.
howcome: It's such a cheap and easy switch though.
anne5: But still, every feature has a cost.
jdaggett: [shows off another japanese website]
fantasai: In a case like this your design would be completely different
for a different writing direction.
arronei: Which goes back to alternate stylesheets.
szilles: So it seems like what we're discussing betweeen is alternate
stylesheets vs alternate stylesheets + maybe some support
for automatically handling both.
szilles: ON another dimension, there's the question of how to select
thee alternate stylesheet.
<Bert> (I think I'm very close to Anne's view, but I have the impression
that vertical-capability is close to the edge: is it as important
as width in MQ, or is it not?)
howcome: One downside of the alternate stylesheet is you can't do it in
the <style> element.
anne5: You can with a @title on <style>.
howcome: In which case we could also see people building a naming
convention for vertical.
<fantasai> you can define specific class names and have the mode
switches depend on those class names
howcome: Do we think we could make that proposal?
anne5: I think the use-case isn't that strong.
howcome: There's a few thousand years of vertical-text in the east.
anne5: But there's not a few thousand years of the direction-switcher button.
jdaggett: I think I'd say that some of the use-cases of epub can be
handled within epub itself. There are also a whole set
of vertical-text features that are being overshadowed by
these epub features.
fantasai: Right, epub can decide the convention for deciding between
stylesheets.
fantasai: The problem we need to solve here is the fallback issue.
* gsnedders gets tired of nodding agreeing with fantasai, but still agrees
fantasai: A lot of the new layout things we're doing - vertical,
flexbox, template, maybe multicol - completely break
the page if they're not supported.
fantasai: We need a way to detect support for that.
howcome: We can do that in MQ. We don't want to put in all the
properties, but we can detect properties of the environment
in terms of support.
jdaggett: That doesn't solve the default problem, though. Which one
to use automatically.
szilles: I'd like to hear consensus that we do need an alternate
stylesheet mechanism.
howcome: We have that, but we need a convention on how to use it.
fantasai: Or not even quite that - epub has the ability to do some of
that specially. What we want is some recommendation that,
if you offer these config knobs to the user that need
different stylesheets, this is the way to do it.
fantasai: so that if you want a orizontal-vertical switch, or a
high-contrast:low-contrast switch, or a big-text:little-text
switch that's standardized, this is how you hook your
standard set of controls into the alternate stylesheet mechanism
<anne5> (I think the problem with using Media Queries is that they
are not for extracting information, which is sort of what
you want for UI.)
<anne5> (Though I guess you could evaluate the media queries for
the page assuming the preference has either value and see
if there's a difference.)
<anne5> (But I think this feature is not needed at all.)
<anne5> (This feature sounds a lot like 'color-index')
<Arron> Adding to ealier conversation: Using alternate stylesheets
there just needs to be some identifier that UAs can map to.
If we define those identifiers for some of the common cases
then UAs can map their controls to their created alternate
stylesheets for horizontal or vertical, etc...
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Jun/0133.html
TabAtkins: Do we still need the ability to make a single stylesheet
that can handle the page in both horiz and vert?
fantasai: For webpages, generally not. They'll be design-heavy and
specialized for one direction. Books can be either way, though.
jdaggett: I disagree. I think that while books *in general* can be
either, specific books are usually designed to go a particular way.
fantasai: But they offer switching buttons.
TabAtkins: I think that's just to set the device to using the proper
form. It's fobbing off the detection to the user.
fantasai: I don't want to do market research for the japanese market.
They just need to tell us about that.
jdaggett: [brings up another slide, showing mixed uses of different
ways to write mixed english/japanese in a single doc]
jdaggett: Frex, you might have in single text some arabic numbers
written horizontally in halfwidth or thirdwidth characters,
while others are written vertically.
jdaggett: [shows an example of a date, where the year part is written
vertically and the month is written horiz with halfwidth numbers.
jdaggett: [shows an exmplae of an article including both a horizontal
section and a vertical section together, where the same word
"iPad" appears in both sections, in both direction]
jdaggett: shows an example where horizontally-written numbers in
horizontal japanese text also use halfwidth characters]
jdaggett: This points to maybe needing some type of text-transform,
from fullwidth to halfwidth or something.
jdaggett: [shows an example where a short word "iPhone" in vertical
text is written vertically with normal characters, while
a longer word "i.softbank" is written horizontally and
then rotated vertically]
fantasai: We'll have some switches for these types of things.
alexmog: Is "iphone" in full-width characters?
jdaggett: Typically the latin will be in normal codepoints, but we
might have a CSS feature to switch it into fullwidth characters.
jdaggett: I wouldn't say that fullwidth characters would probably ever
be used in the "layout as normal then rotate the whole span" case.
ChrisL: Important and interesting a11y issue here - if you can write
"iphone" in ascii and use CSS-switch it to using the fullwidth
characters, you can actually search for it. Good luck searching
with fullwidths.
* fantasai notes that Unicode matching algorithms probably handle that
szilles: About the "1GB" part in that example (currently written vertically),
would that be a case for writing with halfwidth glyphs so
you can write it horizontally?
jdaggett: That's very rare. It's not what's done right now.
fantasai: Without special support for "writing an english word
horizontally embedded in a vertical line" you can just use
inline-block and set writing-mode as appropriate.
fantasai: Or just an image.
jdaggett: That would screw up the typical japanese way of doing things.
We shouldn't do that automatically.
fantasai: How is the "30" (done horizontally) typically done?
jdaggett: You just use two half-width glyphs.
fantasai: We can do that. Wrap that in a span and set some property,
and it'll merge them together.
jdaggett: Right, and maybe we could even do that contextually.
Just anywhere you find 2 half-width characters together
it automatically does it.
Bert: What about, say, a license plate that happens to have 2
consecutive digits? That would screw it up.
jdaggett: Right, it might not work at all times.
fantasai: We'll look into if we can do it contextually, but it may
not make css3.
alexmog: Are there any design programs that do this automatically
contextually?
jdaggett: Not sure right now.
<Bert> ('block-flow: tb-only-if-short-enough' with a better name.)
szilles: The inDesign guys were in favor of marking it up.
JohnJansen: I think there's a way to hit 80% here and then allow an override.
jdaggett: [shows a magazine page where many different sections
have different modes]
szilles: Body text is often vertical, while callouts and captions
are often horizontal.
jdaggett: My point is that I think this kind of vertical text layout
leads a lot to grid.
fantasai: This has no more to do with grid than layout in a horizontal-
only magazine.
szilles: In general, the directional statement lies with the content today.
fantasai: I think you'd just assign it to different elements.
The sidebar is horizontal, etc.
szilles: That presumes I know where the element is going in the template.
TabAtkins: If you have multiple templates, you'll have multiple blocks
of styles, so you can assign writing modes appropriately for each.
fantasai: As far as the coarse layout is concerned, this page doesn't
give you any more problems in japanese than it does in english.
jdaggett: But if you don't consider japanese cases, you may make
assumptions that break things.
[something about overflow]
jdaggett: It sounds like you have a bunch of info in notes?
fantasai: Yes, that's why I'm going to write this next month.
howcome: I think from this topic we've kind of decided we don't need
these logical directions?
fantasai: We didn't decide that. We'll be investigating that in TPAC
with the i18n WG.
howcome: I'd like to record that, then, and also record that we think
that alternate stylesheets are a good way to go.
fantasai: Agreed.
szilles: What are the weaknesses of alternate stylesheets? Duplication
of info?
jdaggett: I think I'm done. Is there anything else to say?
szilles: I think that maybe the logical may make more sense for bidi
than for vertical.
howcome: I just think that adding duplicate sets of properties is a big pain.
howcome: And it won't end. You may want margins dependent on whether
it's a left or right page, for example.
[discussion about the conflict between margin-start and margin-left, frex]
[and about which one gets used, when you can determine that, and how
much data you have to carry around]
anne: you decide after parsing, not during
anne5: When you start laying out the element, you know the writing-mode
computed values.
dbaron points to http://fantasai.inkedblade.net/style/discuss/directions/box-switch
which has one value always take precedence at computation, not layout.
Alex: The margin-outside example is much more complicated
Alex: You can only resolve this during layout
howcome: You still have to double-book and carry both around.
Alex: So you must have a separate storage value for margin-outside
<fantasai> Values are easier to deal with
howcome: And then there's all sorts of other properties, float and
clear and caption-side and background.
howcome: And what about the top/bottom/left/right properties? Do we
need start: and end: and out:?
fantasai: There are two different proposals that have been decently
fleshed out for how to cascade these.
fantasai: One by me, one by dbaron.
fantasai: But I don't think that either work for margin-outside.
fantasai: Becuase you don't know what page it'll be on, and thus
which margin -outside maps to, until layout time.
Alex: You need six real values and 10 virtual values
anne5: Do you need this for vertical?
fantasai: It would be helpful, for example to make lists with gutters
for the bullets.
Alex: left/right/etc an map at cascade time, outside/inside would have
to map at layout time
jdaggett: The key point is simplifying things. It makes it simpler
because you have to write less properties, but it's not
strictly necessary; you can do it other ways.
jdaggett: To me it's not just the number of core properties that need
to be added, it's the number of other modules that have to
make it work.
jdaggett: Like border-radius now needs border-radius-startbefore.
howcome: That hurts. But what about lists? Does the :ltr and :rtl
work for that?
fantasai: Yeah, that should solve it.
anne5: And what about switching the meaning of physical properties?
fantasai: No. But we need to discuss it so I have a good answer when
I talk about it later for why we're not doing it.
TabAtkins: It sounds barely reasonable for vertical text because
you're rotating, but it makes no sense with rtl languages
where it mirrors, and margin-right becomes left an
margin-left becomes right.
<dsinger> dave suggests (a) that we find examples that contain horizontal
text and make sure the examples work with vertical text and
(b) find occurrences of direction-sensitive words in our specs
(top, left, bottom, right, above, below) and check that we mean
that physical direction (we saw an example yesterday which
started direction-agnostic and then went on assuming ltr text)
alexmog: Idea for specifying multiple new direction values without
producing new properties.
alexmog: "margin:out(10px); margin:before(20px);" overriding whatever
direction the out or before directions would be.
ACTION Alex: Send proposal on "margin:out(10px);" and similar to the list
for discussion.
<trackbot> Created ACTION-263
RESOLVED: Physical directions stay physical - margin-left will always
refer to the left side, not the top or right side based on
physical direction.
#rrggbbaa
---------
Scribe: fantasai
Tab: I have a patch pending in WebKit to support 4-digit hex format
Tab: A lot of designers use hex format, it's a pain to switch to
rgba() when we want to add opacity
dbaron: In HTML, hex parsing is fixed up. but not in CSS
Tab: The patch is mainly just pending me putting this into a spec draft
Tantek: I don't want to add this to css3-color
Tab: No, I want to add to css4-color
Tab: Other question is whether serialization tests should go into
css3-color testsuite
Anne: CSS4 Color spec should define the OM data type
RESOLVED: Add #rrggbbaa to css4-color
Bert: I'm against adding new features.
Bert: I'm against CSS4.
ChrisL: Then you shouldn't be on this committee
Bert objects to adding #rrggbbaa.
All others in favor
glazou: Raise a formal objection if you want. Change the chair. I don't care.
dsinger: if there is an objection, tell the list what problem you
see in case I (or others) have missed something
CSS3 UI
-------
Scribe: TabAtkins
<tantek> http://w3.org/tr/css3-ui
tantek: It's been 6 years since we had UI CR.
tantek: A large number of these features have been implemented, but
not everything.
tantek: Some was at risk, but some of the non-implemented stuff wasn't
marked as at risk.
tantek: And some just weren't implemented the way the spec says; maybe
we don't want those anymore.
tantek: So I propose that anything that hasn't been mplemented by at
least two impls should be dropped.
tantek: Add a couple of things that have been implmented and belong
here, like pointer-events and overflow-x/y.
anne5: You want to move overflow to this module?
tantek: It was there originally, but it got moved to Box. Since
then we've just backported overflow fixes to 2.1.
glazou: Tantek, you seem to be dropping a long list of features.
Do you think anything will soon be implemented?
tantek: It's been 6 years. I don't have much hope for a rapid implementation.
anne5: "appearance" has been implemented in at least two browsers.
tantek: Yes, but not the way the spec has it. It's basically a
different feature with the same name. So it's not for UI3.
<anne5> (I actually thought it was implemented somewhat like the spec,
but then I never fully understood the spec)
tantek: So my plan is to chop it down, short LC, short CR, then to PR.
tantek: Gist of things I want to add to UI4 is -
tantek: HTML5 has introduced a bunch of new form UI.
tantek: For example, a placeholder can be put into form elements.
tantek: Authors want the ability to style that placeholder.
tantek: In Moz we had enough requests that we implemented in prefixed.
tantek: So, analyze HTML5's new form stuff, see which parts need to
be ported back to CSS.
jdaggett: What about these "system font values".
dbaron: They're in 2.1, actually. Not the entire list, but a lot of them.
tantek: So that's the plan there - see if any of the further values
have been implemented. If so, great; if not, drop them.
anne5: I'd like to see those fonts things moved to the Fonts module.
<anne5> especially since defining 'font' in two separate modules is
just a bit too much, imo
tantek: These keywords are defined in terms of UI features.
[discussion about the keywords being very windows-based]
jdaggett: tantek, will you be counting prefixed properties as
"implementations"?
tantek: If they're implemented the same way they're specified, that's
just the impl being conservative, so yes.
fantasai: I suggest putting the selectors in a separate draft "Selectors UI",
so other specs like the QuerySelector API can reference just that.
tantek: I wouldn't have a problem with doing that for *new* selectors,
but I want to keep the current selectors in UI and just move it
through. Doing otherwise seems like unnecessary editorial work.
arron: You can't publish css3-ui until the new charter
fantasai: But if you pull out the selectors and publish them separately,
you can publish that now
fantasai: because selectors fall under our current charter
Tantek: I'll consider that.
tantek: Also, could implementors tell me what properties from UI they claim
to have implemented, so I can just trust that? 3 weeks deadline.
<fantasai> Splitting out a draft doesn't take long. I can do that kind of
thing it in one or two hours.
ACTION Daniel: At next telcon, remind people about Tantek's request for
impl claims for UI stuff.
<trackbot> Created ACTION-264
CSS2.1 Dates
------------
johnjansen: I wanted to get a date for when impl reports could be available.
johnjansen: I also made an assumption that impl reports should always
be on the w3c site, but that appears to be incorrect.
I'd like an affirmation that we will post them publicly.
glazou: You said that to run the test against an impl takes 2-3 days.
johnjansen: Yes.
glazou: We may find a few bugs while running the tests, so we can
probably dedicate a month for that.
dbaron: I think that 1 month after test-suite completion sounds fine,
especially if we can write it that way.
fantasai: I want to reiterate that the test suite is basically complete.
some fixes may need to be made, but we always give notice of
that, so if you want to start impl reports now you won't be
wasting your time.
<fantasai> specifically, I list all tests that have substantively
changed (and would therefore need to be rerun)
More Fonts Stuff
----------------
<jdaggett> http://people.mozilla.org/~jdaggett/webfontsfuture.pdf
szilles: One of the problems with fonts in CSS is that it would be nice
if there was a way to take a font-family name and finding the
font that would work for it on all platforms.
szilles: The problem is that there isn't an easy way to do that.
jdaggett: The underlying problem is that the original truetype spec
has a bifurcation. the font-family name can be different
on mac and windows.
jdaggett: Then along the way there were questions.
jdaggett: One was what to do with old applications that only have a
bold and italic variation.
<szilles> jdaggett: In the TrueType spec, at least two font family
names are allowed, one for the Mac Platform and one for
the Windows platform
jdaggett: So one solution was to create a new, separate name for
Windows that would denote the larger family.
jdaggett: So you have one font-family that's the basic level, another
more general one.
jdaggett: Then they looked at CSS and saw the font-selection model.
<szilles> Microsoft and Adobe agreed on a name that covers a wider
set of variations than the orignal Windows font family
name covered
jdaggett: If you put in things that can't be defined by -weight,
-style, -stretch (Adobe has faces for optical sizing, frex),
there's no way to select it.
jdaggett: So they came up with a third name.
jdaggett: So as it stands, there are 3 names defined for windows,
and 1 defined for mac.
jdaggett: So when you say "I want font xxx", what should be given to it?
<szilles> This means that there are three names defined for Windows
and an additional one for the Mac
jdaggett: For most fonts it's okay, but for adobe fonts there's a problem.
It's understandable, but the font-family that a user is seeing
is system-dependent.
jdaggett: So it's not a problem of CSS doing the wrong thing, it's the OS
displaying a different family name for the exact same font-file.
jdaggett: So unless you can get Apple to agree to look at those names,
there's nothing we can say.
jdaggett: I think it's fundamentally wrong to say that you should select
fonts based on a name the user isn't seeing.
jdaggett: If I go to Fontbook on my mac, I should be able to write a
document using that name.
jdaggett: For 99% of cases, this isn't an issue. Our model is sufficient.
It's only for designers building large families that we need a
higher selection model.
jdaggett: Adobe suggested using the WWS name, but that's a windows-only
name, which is weird.
jdaggett: One way to solve it would be to say that if a family has more
faces than the CSS model can represent, you can select it by
the specific WWS name.
jdaggett: But I think the fundamental answer has to come from apple.
dsinger: We're only using one name!
jdaggett: Right; the original problem was just solved by apple in a
different way.
<ChrisL> but the apple name is not exposed through windows api's
jdaggett: At Moz we're going to bring in the TypeFont manager or whatever
at Apple and we're going to try and figure out something.
szilles: I just wanted to make sure we recorded the nature of the
problem and encouraged solutions.
jdaggett: I think the proposed solution isn't bad, but fonts have a
fundamental incongruity outside our jurisdiction that makes
this a sticky problem.
[does this issue affect webfonts?]
jdaggett: No, because @font-face doesn't care about the name in the
name table, only the name in @font-face
::selection
-----------
glazou: Next topic, ::selection.
<glazou> http://lists.w3.org/Archives/Public/www-style/2010May/0275.html
howcome: This was pulled out of the Selectors spec, so it's not in any
working draft now.
glazou: No, but we have partial impls, though not really interop.
glazou: Some visually impaired users rely on it because it lets you set
the colors and background of the selection.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
howcome: What draft would it be in?
glazou: Either Selectors 4, or UI 4.
dbaron: Last time we discussed this I brought up a summary of these
issues (above url).
dbaron: I brought up five requirements, and I'd like to know, for any
proposal, which requirements it breaks.
dbaron: the first one is that the appearance of a piece of text when
it's selected shouldn't depend on the root container of the
selection (nearest common ancestor of the endpoints).
dbaron: So you shouldn't get into a situation where extending it by a
few characters changes the whole thing.
glazou: Sounds reasonable form a user perspective.
dbaron: Second is that the default selection style should be
representable in pure CSS.
dbaron: Third is that author styles should override system styles.
dbaron: Four is that the background and foreground color of the
selection should always override the back/foreground of the
unselected text.
dbaron: So you don't want to get into a situation where an inline
with a background shows its background, not the selection background.
dbaron: And Five is that selection style should be settable per element.
dbaron: In the previous discussion, the models we discussed didn't
meet these requirements.
dbaron: So I want to be careful that if we violate these requirements
we do so knowingly. I'm hesitant to break them.
sylvaing: #4, does that mess with specificity rules?
dbaron: Not necessarily - it's a pseudoelem so we can do what we want.
glazou: And the fifth rule implies you have some sort of hierarchical
inheritance of ::selection.
dbaron: We should probably go back and look at francois' message so we
can better understand these.
dbaron: Though possibly this is best done on-list.
glazou: I think using these requirements is pretty trivial to create
an algorithm.
dbaron: Yeah, I was able to create three possibilities that did so
(one maybe failed #5), but they were all somewhat messy.
dbaron: In one, *::selection is handled badly. I describe it in the message.
dbaron: Because it makes *::selection override elem::selection in
descendants of the elem.
dbaron: Maybe it's not that bad; it just makes you represent the
system default as :root::selection
glazou: I'm not sure it's a bug. Sounds like a feature.
TabAtkins: Yeah, as long as we have a way around it, this doesn't
sound too bad. An author probably won't do *::selection itself.
dbaron: But there may be existing content using that.
dbaron: B & C both introduce a new cascade concept for ::selection.
dbaron: I'm sorta coming from an unusual perspective, though, since I'm
from the only vendor who's implemented it with a prefix.
glazou: Sounds like most people either haven't read the message or
read it too long ago, so it's not worthwhile to talk now.
glazou: But we all know about and agree on the five requirements.
We know what we want, if not how to implement it.
glazou: I suggest, since we won't have to discuss 2.1 issues on the
conf calls, let's give some time to study existing impls.
dsinger: If we could take existing impls and check how well they match
the five requirements would be useful.
glazou: Yes.
rune: I implemented ::selection in Opera.
howcome: Opinions on where we should go with this?
rune: Nothing yet, but I can give some thoughts based on our impl.
rune: It's implemented using synthesized selection color and bgcolor,
which are the only two properties we support.
rune: Those two properties are inherited by default.
glazou: From selection to selection?
dbaron: You're saying you treat the pseudoelem as two virtual properties?
rune: Yeah.
dbaron: It sounds like what you do is basically similar to my proposal A,
or possibly more like B.
rune: I don't directly remember what we did with inheritance.
rune: Whether we inherit from the real color property, or...
dbaron: I think I don't much care what explicit inheritance does, and
we should just define what works for this.
<glazou> sylvaing: can you hear well over jdaggett's speakerphone?
* sylvaing glazou, yes, it's ridiculously good even when people are far
away it's very clear
* sylvaing ...and i heard you ask from the other room
* jdaggett sylvaing:
http://www.amazon.com/Communicator-Grey-C100S-Speakerphone-Skype/dp/B000GG0EFY/ref=sr_1_3?ie=UTF8&s=electronics&qid=1282747958&sr=8-3
dbaron: Let me restate and see if you agree.
dbaron: Basically you take any selector with ::selection, and treat it
like that selector minus the ::selection, find the color and
background properties and map them to an additional pair of
hidden properties.
dbaron: Then you cascade those as normal, and use the hidden properties
for things inside the selection.
rune: We're not mixing colors - if you have two partially transparent
colors we just paint the selection color, not the composited version.
rune: But maybe we could change that.
dbaron: We should probably do more research here.
list-style: auto
----------------
<glazou_> http://lists.w3.org/Archives/Public/www-style/2010May/0328.html
TabAtkins: [summarizes the thread]
dbaron: Getting this right would require a lot of work to define how
things map well.
dbaron: Actually doing it in an impl would be easy; the hard part is
writing the spec for it in a sufficiently detailed manner.
* fantasai agrees with Aryeh and dbaron
dbaron: So if someone brought us a table of language->liststyle mappings
and the i18n group approved it, I'd do it. But I don't think
it's particularly worthwhile for the group itself to work on it.
szilles: Maybe we should ask the i18n group to prepare the table for us.
fantasai: They have way more important things to work on.
szilles: One comment - the w3c has comments at a top level that it's
hard to use its specs in various countries.
szilles: Which we're interested in having happen.
szilles: So maybe I agree that it shouldn't be asked of the i18n group,
but I want to record it as something we might want.
szilles: I might even want a registry rather than a spec for the mapping.
Indic Layout
------------
ChrisL: Speaking of that, I have a doc I got from the w3c indic group
about the requirments they have for indic languages to be
represented properly on the web.
ChrisL: Some of this is just browser bugs, but there's also useful
things for us to look at.
ChrisL: First thing - ::first-letter.
ChrisL: You have syllables and sometimes vowels that join onto the
first letter, so what is actually the ::first-letter?
fantasai: We discussed this a while ago.
anne5: Can we have that doc?
ChrisL: Not officially yet, but I expect soon.
howcome: Didn't we define this as "grapheme cluster"?
fantasai: CSS3 does, though there's a lot of useful stuff in an
informative note because no one wanted to make it normative.
fantasai: One of the big problems was we had no exmaples, so this is
really useful and we should thank them.
ChrisL: Now list numbering.
ChrisL: Languages with the same script may use different ordering for bullets.
TabAtkins: Lists3 already allows for that; if there are langauges we
have together now that should be separate, we'd love to know.
ChrisL: Underlining!
ChrisL: In some indic scripts you have marks down below that are
important to tell what's the information, and the underline
can cover that up and make it impossible to read.
jdaggett: That's controllable by the font - if you're getting overwritten
you're using a garbage font.
ChrisL: Okay, so this may just be a browser bug. We can respond and
tell them that.
jdaggett: Also, I see a lot of <p> without @lang attributes, so font
selection is totally UA-dependent.
* sylvaing must track down the name of the young indic type designer
who presented at typecon on friday
jdaggett: For strikethrough, it's used as an editting mark in English.
Is the equivalent editting mark the same there?
ChrisL: So that's the information. I've asked to be able to send this
to the list for wider discussion.
ChrisL: And this isn't a one-shot; they want to work with us.
glazou_: Welcome!
CSS Template Layout
-------------------
glazou_: Next topic, template layout.
CesarAcebal: I didn't prepare anything specifically for this.
CesarAcebal: What I'd be interested in, though, is finding out what
your opinion is on the state of the module.
CesarAcebal: What's the priority, etc.
CesarAcebal: Or, what do you want to change.
fantasai: Hyatt posted to the list a while ago that it's not possible
to prefix anything in the syntax so you can't do an
experimental implementation.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0191.html
fantasai: He had good ideas to solve that and that would also make it
easier to find out what is going on in the stylesheet if you
are reading a stylesheet and are not familiar with the syntax.
jdaggett: What's the relationship between Grid and Template?
TabAtkins: They're complementary, but not directly tied together right
now. But I and Alex want to explore options to merge them further.
jdaggett: Any implementations?
Bert: Two javascript implementations, and one in Fedenouik's HTMLayout engine.
alexmog: MS is interested in grid and other similar layout type things.
I'm not prepared right now to give specific promises now, but
maybe we can talk more specifically in the future.
howcome: Do we have specific examples of how this would work in use?
TabAtkins: I've spent time exploring how layouts of Facebook pages,
CNN, etc. would work with Template and Flexbox.
jdaggett: Could you publish those to the list?
TabAtkins: Yes, and I'll continue doing these types of things for any
new ideas.
jdaggett: I think it would make me feel a little better if these things
were somewhat combined.
sylvaing: Agreed. It would make it easier to see the value of these.
CesarAcebal: I am convinced that Template Layout makes so many layouts
much much simpler than anything that currently exists.
Bert: There are some examples in the spec and in Cesar's thesis with
Andy Clark doing experiments with it.
CesarAcebal: My thesis PDF was posted to the list.
CesarAcebal: As a personal opinion, a summary, I think the major
difference preferring Template over current layout
mechanism is that is allows us to define the layout
of the whole page in an explicit way.
CesarAcebal: Currently we lay out pages by saying that this element
floats, this element positions like this, etc. The
final layout is only known after all the interactions.
CesarAcebal: Template Layout, you just say "I want two columns" and
then you put elements in there.
CesarAcebal: I also believe that with Template Layout it would be
very easy to have gui tools to work with CSS layouts.
CesarAcebal: When you show a designer the prototype, they always say
"Woah, when is this going to be on the internet?".
fantasai: I poste the url to Hyatt's proposal to make prefixing easier.
If people agree, we can resolve this.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0191.html
[general agreement with it]
Bert: I don't want an extra property
dbaron: You can still do an experiment with the extra property even
if it's not in the draft.
Bert: I'm not in favor of the new property it introduces.
glazou_: Hyatt said that it *cannot* be implemented as written because
you can't introduce a prefix.
fantasai: could also put a functional notation in the display property
around the template
dsinger: Let's circle back to Hyatt and see if he needs his specific
suggestion or if something else would work.
dbaron: Using a function also means we don't permanently use up the
<string> syntax.
fantasai: And using a property or function also means one can search
for the name for that function.
dbaron: I think the functional notation is reasonable permanently
because it doesn't use up the string value permanently,
just a function name.
RESOLVED: Edit the Template spec in some manner to make it possible
to do vendor experimentation.
fantasai: [writes up some syntax options on the board]
fantasai: First is about slots. Hyatt suggests using "position: slot(a);".
alexmog: And that would allow "-webkit-slot(a)" during experimentation.
fantasai: And then actually defining the grid.
fantasai: Hyatt suggests a "grid-template" value for display, which
then looks to the value of a "grid-template" property.
fantasai: Someone else suggested a "display: template(foo)" function.
fantasai: And Bert suggested putting a "-vendor-template" token as the
first value of display.
fantasai: Keep in mind that templates will usually be multiline strings.
fantasai: And second option for position, similar to Bert's proposal of
a vendor token.
<jdaggett> First questions
<jdaggett> A. position: slot(a)
<jdaggett> B. position: -prefix "a"
<jdaggett> Second question
<jdaggett> A. display: grid-template;
<jdaggett> grid-template: "aaa"
<jdaggett> B. display: template("aaa")
<jdaggett> C. display: -prefix "aaa"
glazou_: A, A.
jdaggett: A, B
CesarAcebal: A, B
ChrisL: A, B
TabAtkins: A, B
tantek: abstain
JohnJansen: A, A
arronei: A, b
dsinger: A, A
anne5: abstain
dbaron: A, B
alexmog: abstain
howcome: abstain
Bert: don't care, C
szilles: A, B
gsnedders: abstain
fantasai: A, B
<jdaggett> results:
<sylvaing> agrees with A, B
<sylvaing> needs to go. thanks everyone !
-sylvaing
Poll results: IA: 11, IB: 0. IIA: 4, IIB: 7, IIC: 1.
CesarAcebal: [shows off some examples of template layout, which he
used in his thesis defense]
<Bert> -> http://code.google.com/p/css-template-layout/ adeveria's
jQuery-based template layout prototype.
Vendor Prefixes on calc()
-------------------------
dbaron: One thing we've been hearing from authors is they really
don't like vendor prefixes when multiple browsers implement
dbaron: So I'd like to be able to drop prefixes sooner
dbaron: I'd like to ship calc() without prefixes
* mollydotcom thinks designers and devs don't understand the reason
and rationale behind vendor prefixes
* mollydotcom also thinks they use that as a means to blame browsers
for not implementing what they want, when they want it
howcome: The problem here is that we're getting to the point when we
need to implement others prefixes
glazou: Question is, is calc() stable enough that we can remove the prefixes?
dbaron: There are 2 implementations in progress, that I know of
dbaron: If we're planning to do this, we should ask www-style fo
comments first
fantasai: Is the rest of Values and Units ready for Last Call?
dbaron: One comment about calc(), specifically
dbaron: For the subset that we're implementing, it's hard to imagine
that it would mean something else.
Tab: We only have lengths, which you can add, and you can multiply or
divide by numbers.
Tab: I think that's safe enough.
Steve: I would file a formal objection, because the process is supposed
to allow for a Last Call period before call for implementation
Bert: It's not illegal for implementations before CR, but it's wrong
for us to encourage implementations.
JohnJansen: I would ask if we can take calc() to CR faster.
fantasai counter-proposes taking the whole module to CR
discussing moving css3-values to LC/CR
ACTION dbaron: Make a list of at-risk features, and list of features
that should be dropped for rapid movement to CR
<trackbot> Created ACTION-265
dbaron: I would mark vh, vw, and vm, fr, and gr.
fantasai: Are fr and gr used for anything yet (aside from layout drafts)?
no
fantasai: Then let's drop those, keep the v* sections
fantasai: And mark the things in dbaron's list as at-risk
fantasai: Someone commented that vm is no longer necessary now that
we have min/max
dbaron: We might want to also mark min/max at-risk
Ok, we're done
Meeting closed.
Thank you Håkon!
<glazou_> ADJOURN !!!
glazou_: Side-note about Lyons, you have to register and pay a fee
glazou_: Also, the hotels near the conference center are expensive and crap
glazou_: And there are not many hotels in that area
glazou_: Also Lyons is very busy at that time, so I recommend booking your
flights and hotel asap
* dsinger Hotel Roosevelt: http://www.booking.com/hotel/fr/hotelrooseveltlyon.html?aid=309824;label=postbooking_confemail
Received on Wednesday, 1 September 2010 03:11:40 UTC