With new devices popping up all over now with different screens of shapes and sizes would it make more sense for these changes to have further clarity around different display shapes?
Some devices that don’t fit this:
The cut off part of the screen here would have to be masked off leading to custom device profiling.
You could probably argue this is covered by the specification however it certainly highlights the issue further.
There is also the VR headset boundaries that could be handled by this too:
Issues for different screen shapes
- No media queries for the different device profiles
- Display is defined as
circle(50% at 50%, 50%) in a regular round display further clarity would be needed around display shape.
- Polar position doesn’t always apply here
- Code example issue in Example 4
// the same as circle(50% at 50%, 50%) in a regular round display
This should likely just be
shape-inside: display; without the
- The Example 6 code is likely the wrong way around:
<div id="circle1" style="polar-angle: 0deg; polar-distance: 20%"></div>
<div id="circle2" style="polar-angle: 90deg; polar-distance: 50%"></div>
Polar distance should be swapped to be:
<div id="circle1" style="polar-angle: 0deg; polar-distance: 50%"></div>
<div id="circle2" style="polar-angle: 90deg; polar-distance: 20%"></div>
To match the image:
It also seems like rules similar to print CSS paging would help displaying on these devices. Overflow gets clipped when using the
shape-inside demo. Issue 2 covers this.
To have text fit into the the shape of the display, normal scrolling wouldn’t work as the text would start reflowing around as the user scrolled.
So I think the only simple way once using shape-inside, the interface would turn to card mode and slice the content into pages which are fixed to the device size.
Transition between one card and the next would need to be definable too.
This also relates to my comments on elements interactive areas:
The round display spec is in really early stages, and needs improvements. Your feedback looks good. Could you send it to the www-style mailing list?
This isn’t quite solved yet, but pagination on demand based on overflow is being worked on: http://dev.w3.org/csswg/css-overflow-3/#fragmentation
A whole lot more work is needed before that’s usable, but once finish, it should fit right in with this rounded display situation.
Sent over to the working group.
Like you say mostly it would be solved by:
Transitions between paging would be nice but certainly that isn’t a high priority right now.
Thanks for your comments.
I’m Hyojin Song who is an editor of the CSS Round Display spec.
The first issue you indicated is exactly right, and I’ve applied the issue. I think you have an eye like a hawk Even though I reviewed the spec with deliberation, I didn’t catch the error.
For the second issue, I think it depends on where is the major axis, and it is normally the right direction as the 0 degree. You can find the background materials in the wiki page as follows. http://en.wikipedia.org/wiki/Polar_coordinate_system
If I’m missing something, Feel free to let me know.
Thank you for your interest and support of the CSS Round Display.
There is a different precedent in
For the purpose of this argument,
0deg points upward,
and positive angles represent clockwise rotation,
so 90deg point toward the right.
Although, if I remember correctly, this detail has changed at least once in the various proposals for standardizing CSS gradients.
Gradients used to have 0deg pointing to the right, to align with standard polar coordinates, and positive angles go CCW. But SVG uses bearing angles, with 0deg pointing up and positive angles going CW, so I aligned with that.
Everything in CSS that uses angles for directions should do the same.