Skip to content

Workweek writing modes

Josh Matthews edited this page Jul 8, 2014 · 1 revision

Writing modes

http://dev.w3.org/csswg/css-writing-modes/#vertical-intro

(discussion of writing mode requirements and examples)

  • simonsapin: we switch to calling it inline size and block size instead of width and height respectively.
  • simonsapin: bad news is that we have to rewrite all of layout. instead of using physical directions like x and y, width and height, we have to change it to logical directions. there is not just one abstract space but two. flow relative space is based on inline direction and block direction. and there is the special case of mongolian. mongolian is vertical text. and inside one line the left side is considered the bottom (for text-underline), but multiple lines grow to the right. so for that reason there is a third space called line relative space ( http://dev.w3.org/csswg/css-writing-modes/#abstract-box ). in flow there are block-start, block-end, inline-start, inline-end. and in line relative it's line-left, line-right, line-over, line-under.
  • jack: what do you call x and y now?
  • simonsapin: what gecko does is to call them i and b (short for inline and block)
  • patrick: that sounds good to me
  • simonsapin: there are three properties: writing-mode, text-orientation, and direction. together these properties define the writing mode. to avoid writing layout with conditionals everywhere, gecko has geometry objects, points, sizes, rects, that are in flow relative space. the idea is to use these to write layout and have the same algorithm apply whatever the writing mode. you still have to be careful when you mix writing modes in a document. at the point where we change writing modes, you're going to look at the writing mode of the node your'e layout out or its parent. to avoid mixing up logical points in different writing modes, all of the geometry objects know which writing mode they are in.
  • jack: can we use phantom types to prevent mixing this up?
  • simonsapin: it would be difficult because you'd have to make all of layout generic over the types. i don't know how that would work. each point or rect is defined to be in a writing mode, but whenever you use it, the context tells it what writing mode is supposed to be. in gecko, every method, even getters and setters, take a writing mode parameter and use that parameter to do conversion between logical and physical space. in debug builds, there is a writing mode stored in the fields, and asserts that the one stored in the field is the same as the one passed in. this has already caught several bugs. in gecko you have to pass width to the logical->physical transform function because the direction might be right to left and you need (container width - width) to get the coordinate, but gecko doesn't do this in vertical mode. i emailed gecko peole but haven't heard back yet whether this is a bug or not. how should we do this?
  • jack: maybe we could do everything but tables since that seems hard? what about just doing blockflow to start?
  • simon: blocks contains floats which is oen of the hardest cases.
  • jack: how is float: left interpreted in logical space?
  • simon: in vertical text one means top and the other means bottom. (talked about first step of how to phase in writing modes work. perhaps doing the renaming and logical -> physical conversion first, before changing any of the logic or adding support for the new writing modes)
  • jack: when will you start landing the renaming? is there a branch?
  • simon: i have a branch where I started creating the geometry objects, but haven't touche the rest of the code. we need to decide whether we want to take the hammer and rename everything at once.
  • jack: i prefer to do it all at once. it's confusing enough without having both simultaneously.

(we decided to move rust-geom into servo/src/components/geom and move Au form util to geom. bjz/cgmath-rs will be the general geometry library for non-servo use cases. doesn't make sense for the new geom with logical flow units to be in a submodule anymore. there is an email on the list with branch name and proposed renamings and apis. simon will also create a metabug about this to track it.)

Clone this wiki locally