W3C home > Mailing lists > Public > www-style@w3.org > September 2010

[CSSWG] Minutes and Resolutions Oslo F2F 2010: Fonts, UI, Writing Modes, i18n, Template Layout, Values and Units

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 31 Aug 2010 06:59:27 -0700
Message-ID: <4C7D0ABF.5000606@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT