headers
Bjoern Hoehrmann | 19 Jan 2006 18:20
Picon

Re: FW: [ANN] formsPlayer 1.4 gets animations


* Mark Birbeck wrote:
>Here's some advanced notice of a feature that we think you will enjoy. As
>part of the forthcoming formsPlayer 1.4 release we have connected animation
>effects to our event and CSS handling. For example, to make all XForms
>elements shake from side to side when it becomes invalid, just do this:
>
>  .invalid
>  {
>    event-xforms-invalid : fx-Effect-Shake();
>  }

Could you fix that to comply with the requirements for proprietary
extensions in <http://www.w3.org/TR/CSS21/syndata.html#q4>? Thanks.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 0 comments |
headers
Richard Ishida | 24 Jan 2006 18:48
Picon
Favicon
Gravatar

Request for comments: :first-letter in non-Latin scripts


The W3C i18n Working Group would like to gather information about the usefulness, in general, of the
::first-letter pseudo-element in non-Latin scripts, and any particular issues or differences arising
from the different characteristics of the scripts. We would like to hear from you if you have some
knowledge/thoughts in this area. 

Please read the questions at 

http://people.w3.org/rishida/blog/?p=40

and send your comments to www-international  <at>  w3.org
Archive: http://lists.w3.org/Archives/Public/www-international/

Thank you.

(We may adopt this approach as way of regularly seeking feedback on particular issues.)

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
Permalink | Reply | 5 comments |
headers
Najib Tounsi | 25 Jan 2006 21:14

Re: Request for comments: :first-letter in non-Latin scripts


Richard Ishida wrote:

>The W3C i18n Working Group would like to gather information about the usefulness, in general, of the
::first-letter pseudo-element in non-Latin scripts, and any particular issues or differences arising
from the different characteristics of the scripts. We would like to hear from you if you have some
knowledge/thoughts in this area. 
>
>Please read the questions at 
>
>http://people.w3.org/rishida/blog/?p=40
>
>
>and send your comments to www-international  <at>  w3.org
>Archive: http://lists.w3.org/Archives/Public/www-international/
>
>Thank you.
>
>
>  
>
Hi Richard,

I tested  LamAlif letter (Lam+Alif) as a "first letter" with mozilla 1.7 
(http://www.w3c.org.ma/Tests/InitLigature.html). Only the very first 
letter LAM is styled. I was expecting that (nomally) LamAlif as a 
ligature would be considered as first letter.

I am not expert in writing/printing systems. I'll ask some experts 
around here to know more about that.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Boris Zbarsky | 25 Jan 2006 22:55
Picon
Favicon

Re: Request for comments: :first-letter in non-Latin scripts


Najib Tounsi wrote:
> I tested  LamAlif letter (Lam+Alif) as a "first letter" with mozilla 1.7 

For what it's worth, I wouldn't ascribe particular "correctness" to the 
Mozilla first-letter implementation...

-Boris
Permalink | Reply | 0 comments |
headers
Maciej Stachowiak | 14 Jan 2006 23:48
Picon
Favicon

SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


As requested by Jon Ferraiolo, here's a rough cut at reformulating  
SVG whitespace handling in terms of style properties, to eventually  
phase out use of xml:space and to be more compatible with a CDF  
environment. I have Cc'd www-style because I believe that changes to  
CSS may be required.

Here's what the SVG Tiny 1.2 spec says now:

==============

*    default (the initial value for xml:space) - When  
xml:space="default", the SVG user agent will do the following using
a copy of the original character data content. First, it will remove  
all newline characters. Then it will convert all tab
characters into space characters. Then, it will strip off all leading  
and trailing space characters. Then, all contiguous
space characters will be consolidated.
*    preserve - When xml:space="preserve", the SVG user agent will do  
the following using a copy of the original
character data content. It will convert all newline and tab  
characters into space characters. Then, it will draw all space
characters, including leading, trailing and multiple contiguous space  
characters. Thus, when drawn with xml:
space="preserve", the string "a    b" (three spaces between "a" and  
"b") will produce a larger separation between
"a" and "b" than "a b" (one space between "a" and "b").

===============
(Continue reading)

Permalink | Reply | 31 comments |
headers
Bjoern Hoehrmann | 31 Jan 2006 00:55
Picon

Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


* Maciej Stachowiak wrote:
>As requested by Jon Ferraiolo, here's a rough cut at reformulating  
>SVG whitespace handling in terms of style properties, to eventually  
>phase out use of xml:space and to be more compatible with a CDF  
>environment. I have Cc'd www-style because I believe that changes to  
>CSS may be required.

While xml:space suffers from people not understanding it and it beeing
underspecified in many environments, I don't think it's unfixable and
it's certainly more appropriate to use to convey certain semantics than
CSS. I don't see what's wrong with how SVG clarifies application level
behavior to ensure applications preserve the author's intention when
rendering text; the only problem here seems to be that many other specs
fail to provide such clarification.

It's true that SVG white space processing is a bit different from CSS
white space processing, but that's not really unexpected considering
that SVG 1.1 does not support text wrapping, for example. It might make
sense to add features to CSS to re-use the same white space processing
rules for other elements that we have for svg:text, etc. now, but this
would probably lead to interesting results once and if we try to figure
out how CSS and SVG interact for properties they don't share, like

  <svg:text style="white-space: pre" ...>

It seems it's unlikely this would suddenly turn svg:text into something
that supports multiple lines of text. I don't think we should change the
xml:space attribute such that it triggers some DOM transformations.
--

--
(Continue reading)

Permalink | Reply | 10 comments |
headers
Maciej Stachowiak | 31 Jan 2006 04:14
Picon
Favicon

Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


On Jan 30, 2006, at 3:55 PM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> As requested by Jon Ferraiolo, here's a rough cut at reformulating
>> SVG whitespace handling in terms of style properties, to eventually
>> phase out use of xml:space and to be more compatible with a CDF
>> environment. I have Cc'd www-style because I believe that changes to
>> CSS may be required.
>
> While xml:space suffers from people not understanding it and it beeing
> underspecified in many environments, I don't think it's unfixable and
> it's certainly more appropriate to use to convey certain semantics  
> than
> CSS. I don't see what's wrong with how SVG clarifies application level
> behavior to ensure applications preserve the author's intention when
> rendering text; the only problem here seems to be that many other  
> specs
> fail to provide such clarification.

The problem is that other languages leave it unspecified, and de  
facto treat all possible values the same as "preserve". SVG requires  
different handling for "default". This creates significant problems  
when trying to parse SVG with the same XML parser as other XML  
applications, especially

> It's true that SVG white space processing is a bit different from CSS
> white space processing, but that's not really unexpected considering
> that SVG 1.1 does not support text wrapping, for example.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bjoern Hoehrmann | 31 Jan 2006 04:33
Picon

Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


* Maciej Stachowiak wrote:
>Right now the spec doesn't make clear whether "xml:space" triggers  
>DOM transformations or not. Does it?
>
>If you think it should not modify the DOM, but should affect  
>rendering, then clearly it is a presentational attribute, and should  
>be mapped to appropriate properties.

SVG 1.1 notes that this happens after parsing, after DOM construction
and defines things in terms of a copy of the original data, but I see
there might still be some doubt. Maybe there should be a note to the
effect that this just describes subsequent processing and does not
affect what's in the DOM in any way.

Regarding style properties, mapping might make sense, but it's still
more appropriate to use markup rather than style sheets for this. Let's
ignore for a second that XHTML does not allow setting xml:space on most
elements, then you might want to use

  *[xml|space=preserve] { white-space: pre }
  ...
  <p xml:space="preserve">
  some
  text
  here
  </p>

and consider this versus
(Continue reading)

Permalink | Reply | 6 comments |
headers
Maciej Stachowiak | 31 Jan 2006 08:14
Picon
Favicon

Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


On Jan 30, 2006, at 7:33 PM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> Right now the spec doesn't make clear whether "xml:space" triggers
>> DOM transformations or not. Does it?
>>
>> If you think it should not modify the DOM, but should affect
>> rendering, then clearly it is a presentational attribute, and should
>> be mapped to appropriate properties.
>
> SVG 1.1 notes that this happens after parsing, after DOM construction
> and defines things in terms of a copy of the original data, but I see
> there might still be some doubt. Maybe there should be a note to the
> effect that this just describes subsequent processing and does not
> affect what's in the DOM in any way.

The 1.2 spec also says the rules do not affect the DOM, I simply  
missed this before. Nontheless, given these rules, I think defining  
the behavior in terms of properties is a no-brainer.

> Regarding style properties, mapping might make sense, but it's still
> more appropriate to use markup rather than style sheets for this.

If the mapping is there, this would be up to authors, which is fine  
by me. Although if "xml:space" has effects on text rendering that  
differ per language, using it in a CDF context would be extremely  
tricky.

> Let's ignore for a second that XHTML does not allow setting
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bjoern Hoehrmann | 31 Jan 2006 08:33
Picon

Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace


* Maciej Stachowiak wrote:
>If the mapping is there, this would be up to authors, which is fine  
>by me. Although if "xml:space" has effects on text rendering that  
>differ per language, using it in a CDF context would be extremely  
>tricky.

Note that default behavior without any xml:space attributes is
already inconsistent, I'm not sure xml:space adds much to that.

>You can't correctly mess with the text in HTML at all unless you  
>implement CSS and how how HTML presentational attributes are mapped.  
>And even if you can figure out the current whitespace mode, the  
>author may later use a different stylesheet, or may change the white- 
>space mode via script, or may transform the document via XSLT.
>
>So if a tool wants to mess with your whitespace, it simply cannot  
>avoid the possibility that it will break some documents.

Well, I'd say that's why the XML gods gave us xml:space...
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 0 comments |

Gmane