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

[css3-writing-modes] Memory-saving approach to think about logical directions

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Tue, 26 Oct 2010 06:33:50 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA36341DF@MAILR001.mail.lan>
I would like to propose a different approach to look at logical directions.

I understand one of Håkon's concerns is the memory consumption. I take it seriously. I don't want to slow down my browser either, although you must be far more serious than I am.

On the other hand, I hope us all understand how big the demand for the logical directions is. It's coming back again and again, I understand some of us are a little tired to continue this discussion, but it's coming back because the market demands are so big. As John said, it's true that we can't do everything market demands. That's true, but it's also true that the bigger the demand is, the harder we as technical designers should try to solve. We may end up being unable to solve for whatever reasons, but this one I believe is worth to spend more efforts to resolve.

34 properties per element isn't small amount of memory, I agree with it. But to be honest, to serve the requirements, I don't think we need that much memory per element. The way we ended up here now is the accumulation of several decisions we have made so far. Those decisions should have had good reasons, but I'd like to propose us to think from opposite direction this time; how much memory do we really need, and are there any designs that can achieve it by making some compromises we couldn't do with the approach we have taken?

I understand this is not a regular approach we should take. But I think this issue is worth try unusual methods to see if we can have a reasonable resolution where everyone can be happy.

As Kida-san mentioned before, we probably can't avoid switch per element. So, some amount per element is probably unavoidable. I'm wondering we may be able to reduce further here, as switching directions per element is required, but logical/physical switch may not be. But let's leave this for the next step, for when we need to reduce further.

34 new properties are not required as mentioned above. Do we need a switch per property? My personal opinion is no, we don't need it either. Some may say we do though, and it may be required from CSS design philosophy point of view.

This give us a picture that, from the requirements point of view, only 1 bit (or 2 bits to consider inside/outside case) per element, or 1-2 bits per 34 properties (which is 9 bytes) per element should be the minimal requirements.

I haven't come up with a good design to achieve this yet, nor have idea if we can come up with such design. But I'm leaving it for now.

The question for now is, do we think this is a reasonable addition for browsers to respond to this demand from East Asia and RTL scripts? Or do we need to decrease more?

Received on Tuesday, 26 October 2010 10:31:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC