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

margin:before(1em) -- functional option for logical values

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Mon, 20 Sep 2010 18:49:35 +0000
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928411C20E5F@TK5EX14MBXC218.redmond.corp.microsoft.com>
There is a pending issue for new writing modes (especially vertical) on what can be done to make one stylesheet work in all writing modes.

We had a brief discussion at F2F on a syntax option that would allow specifying logical values without adding many new properties. I have an action to write it up, here it is.

BACKGROUND

All directional CSS properties are defined as physical (so e.g. "margin-left:1em" is always visually left). But if the design intent of 'margin-left' is to add space before start of each line, it need somehow to be changed to 'margin-right' in RTL, or 'margin-top' in vertical.

I will not try to revisit all related discussions (details can be found in this mailing list). Just to summarize the current state of affairs,


*         Switching 'xxx-left', 'xxx-top' etc. from physical to logical is not an option.

*         A global mode that changes all or some properties to logical is possible, but appears dangerous. There is no precedent for mode-changing properties so far (although 'box-sizing' could be considered a precedent).

*         A matching set of logical properties for each directional properties is easy to define, but it creates an explosion of properties.

In particular, the last option adds a logical property everywhere where it makes sense, e.g. for various writing modes:

                margin-start (the side of beginning of text lines)
                margin-end (the side of ending of text lines)
                margin-before (opposite of block progression direction)
                margin-after (block progression direction)

and also, in paged media for changing properties on left/right pages (these have more complicated logical-physical mapping as noted below, and don't necessarily have to be handled with same solution):

                margin-inside (in paged media, inner side of a page)
                margin-outside (in paged media, outer side of a page)

If this direction is taken, a large number of new properties have to be added (including parsing, storage, object model), adding complexity to both implementation and usage. And it gets even worse with properties like "border-before-inside-radius" - that can produce 20 new properties!

FUNCTIONAL SYNTAX OPTION

A "functional option" would allow setting logical values without creating new properties. Instead, shorthand version of property would accept multiple logical values in functional notation, like this:

                margin: before(1em) start(2em);

This approach would not require any new properties. It would still have a number of issues, some old and some new:


1)      Cascading rules for this combined syntax are different. If multiple logical settings are combined:



     blockquote { margin:before(1em); margin:after(1em); margin:start(2em); margin:end(2em) ; }



all settings for 'margin' are to be applied, not just the last one.



2)      Implementations still need to use additional storage for logical properties

a.       Writing-mode dependent properties need storage per style (but not necessarily per element, as they are mapped to physical when writing mode is known)

b.      Inside/outside properties need storage per element



3)      Object model exposure is to be defined. With functional approach, it may be optional to expose logical values in DOM. It may be enough to only expose physical properties and let scripts do their own conversion/mapping.

SYNTAX VARIATIONS

There may be other syntax options with same effect. Not sure which would be more invasive for parsing/cascading rules:


*         margin(before):1em;

*         margin[before]:1em;

These would have exactly same issues listed above, but different for parsing, and may (or may not) be more intuitive to use.

*** Please note that this is not a proposal; I have no opinion at this point if it is better than anything else proposed before. It is a potential direction to consider, with an invitation to discuss ***

Thanks
Alex
Received on Monday, 20 September 2010 18:50:14 GMT

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