Re: [whatwg] Forcing orientation in content
> Not sure if WHATWG is doing anything, but in the W3C there > ishttps://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html in the > Web Apps group Actually I personally have a little more concerns on this API. First of all, some of current mobile browsers provide `orientation` as a number, whose value is among 0, 90 and -90, how would the current API conform to the new one? Secondly, I'd love to see a `orientationLocked` property to check if the orientation of page is locked, this is for several reasons: - It is better to keep unified with the fullscreen API which gives a `fullscreenEnabled` property - I'm a developer on 3rd-party script (e.g. ads), we investigated a bunch of users before and found out that once if a device locks its orientation, they have very little chance to unlock it, so we can provide more accurate and suitable content to a locked screen resolution, it would be much help if detection for whether the orientation is locked is possible. Last, How would it behave if my web app requests orientation locking but is placed in an `` element and the parent browsing context is locked in another orientation? thanks 在 2013-4-18，上午7:03，Charles McCathie Nevile 写道： > Not sure if WHATWG is doing anything, but in the W3C there > ishttps://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html in the > Web Apps group (by Mounir, who works on Firefox OS as a day job) > > I expect to know a bit more about the implementation status of this in about > a week, when the group has a face to face meeting.
Re: [whatwg] ? Please?
(and in this discussion) refers to **definition**, but in most cases above, it should be a key-value pair rather than a term-description pair, the former is more general in semantic, so I think we should have a general purpose key-value pair element such as , (pair name) and (pair content), in such case a user info form could be: Username: John Smith Birth: 2011-01-01 ... This is more symantically structural correct, should be a phrasing element while is a flow element so you can put flow/phrasing content in . Although styling to aligned vertically/horizontally is a matter of CSS but HTML gives a more definitive tag name On Mon, Mar 5, 2012 at 2:56 PM, Hugh Guiney wrote: > On Mon, Mar 5, 2012 at 12:09 AM, Ian Hickson wrote: > > The only thing it adds to the grouping is the ability to have a > subsection > > that is then followed by more content from the subsection's parent > > section. You couldn't do that with alone. However, for > > that's more of a negative than a positive, really (it makes more sense > for > > , , and ; only allows it for consistency). > > In what ways is that a negative? > > > The spec doesn't generally include design rationale. (If anyone would > like > > to help maintain our rationale documentation, please let me know. We're > > always in need of volunteers there.) > > What type of work is involved? > > > doesn't exist. The ability to have multiple types of authoring style > > isn't the reason for 's existence. It's just a side-effect of > now > > having two different ways to mark up sections. It's not actually a good > > thing in language design to have multiple ways to do something (despite > > what Perl might have us believe!). > > HTML is full of multiple ways to do things: a run of text can avoid > and be the child of a if the author prefers, a can > be at the bottom or top of a section, authors can continue to use > Microformats despite the existence of microdata, etc. If language > idealism was a tenable goal on the Web then the WHATWG wouldn't exist > and we would all be using XHTML 2 right now (which had , for that > matter). > > > wasn't introduced as a stop-gap measure. > > > > There's no such thing as a stop-gap measure on the Web. We can't add > > something then remove it. Once we've added something, it's part of the > > platform, forever. That's why we have to be careful to only add things > > that make sense on the long term. > > I only said "stopgap" because you posited CSS grouping as the ideal we > should be striving for, when this method would work today. I actually > don't think this should be taken out at a later time, as CSS grouping > only addressing the issue of styling. It does not address the fact > that—as I outlined in my original post—it is impossible with 's > current parsing model to specify a named value followed by an unnamed > value, since the unnamed value would be subsumed into the preceding > group and be interpreted as an alternate value for it. The converse > (an unnamed value followed by a named value) *is* possible. The spec > claims that the order may or may not be important, yet this forces the > author to write things in a specific order, which may violate what > data they are trying to describe, or in what way. To illustrate: > > > Nameless value > Name > Value > > > > Name > Value > Nameless value? Nope, alternate value for Name. > > > Whereas wrapping either or both Name/Value and Nameless value in > would mirror what is already allowed, but free the author up to use > the appropriate order rather than compromising semantics with multiple > s or non-s. > -- 张立理 GrayZhang 博客：http://www.otakustay.com 微博：http://www.weibo.com/otakustay 邮箱：otakus...@gmail.com
Re: [whatwg] A link[scoped] usecase
Attached image:
http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-0003/code-editor-theme-panel
On Fri, Mar 2, 2012 at 6:59 PM, Gray Zhang wrote:
> Hi all:
>
> I've noticed a scoped attribute for link element has been previously
> discussed, I'm currently working with some new HTML features and find a
> case where the scoped attribute is required on link element.
>
> I'm working on an code editor and building up a scalable theme system, as
> I designed, it should satisfy a list of requirements:
>
> 1. user (3rd party) can publish their theme to my system
> 2. user can preview themes and choose one for their editor
> 3. there is no server side support such as providing a snapshot image for
> skin
> 4. a theme is simply a .css file without anything else
>
> The preview-and-choose panel may look like this:
> [image: Inline image 1]
>
> Each preview pane is constructed with pure DOM, if link[scoped] is
> supported, I could have some elements and text in a wapper, then apply an
> external css on this wrapper so that color/background effect could be
> rendered:
>
>
>
> href="3rd-party-theme/user-published-20120302133702.css" scoped="scoped" />
> function class="identifier">test...
>
>
> By now, for the reason that there is not link[scoped] and style[scoped] is
> not supported for any browser, my solution is add a data-theme attribute on
> wrapper element, and the theme .css file should add some extra selector:
>
> .visual-root[data-theme="fireworks"] {
> background-color: #404040;
> color: #addede;
> }
>
> The addition of [data-theme="foo"] selector is a really bad smell for me,
> in such case I also provided theme author a script to auto generate a theme
> structure, but all these could be solved with the support of link[scoped]
> element.
>
> --
> 张立理 GrayZhang
> 博客：http://www.otakustay.com
> 微博：http://www.weibo.com/otakustay
> 邮箱：otakus...@gmail.com
>
>
--
张立理 GrayZhang
博客：http://www.otakustay.com
微博：http://www.weibo.com/otakustay
邮箱：otakus...@gmail.com
[whatwg] A link[scoped] usecase
Hi all:
I've noticed a scoped attribute for link element has been previously
discussed, I'm currently working with some new HTML features and find a
case where the scoped attribute is required on link element.
I'm working on an code editor and building up a scalable theme system, as I
designed, it should satisfy a list of requirements:
1. user (3rd party) can publish their theme to my system
2. user can preview themes and choose one for their editor
3. there is no server side support such as providing a snapshot image for
skin
4. a theme is simply a .css file without anything else
The preview-and-choose panel may look like this:
[image: Inline image 1]
Each preview pane is constructed with pure DOM, if link[scoped] is
supported, I could have some elements and text in a wapper, then apply an
external css on this wrapper so that color/background effect could be
rendered:
functiontest...
By now, for the reason that there is not link[scoped] and style[scoped] is
not supported for any browser, my solution is add a data-theme attribute on
wrapper element, and the theme .css file should add some extra selector:
.visual-root[data-theme="fireworks"] {
background-color: #404040;
color: #addede;
}
The addition of [data-theme="foo"] selector is a really bad smell for me,
in such case I also provided theme author a script to auto generate a theme
structure, but all these could be solved with the support of link[scoped]
element.
--
张立理 GrayZhang
博客：http://www.otakustay.com
微博：http://www.weibo.com/otakustay
邮箱：otakus...@gmail.com
[whatwg] Deferring image load
We would like to present an authoring difficulty with regard to showing images on the Web with limited bandwidth, when deferring loading of certain or all images are preferable. We have some vague ideas about what browser/markup solutions instead of script solutions might look like, but we are more interested in having the problems solved. Scenario 1. On a product description page of a shopping site, there are several *main* pictures of the product, along with about twenty or so camera pictures of the product taken from different angles. When the HTML is parsed, browsers by default simultaneously start downloading all images, potentially making some of the *main* ones invisible. 2. On an album page where hundreds of pictures are expected to be shown, it is often required that pictures currently in a user's screen should appear as fast as possible. Loading of a picture outside the screen can be deferred to the time that the picture enters or is about to enter the screen, for the purpose of optimization user experience. 3. For a site with limited bandwidth on the server side, it is preferable to minimize the amount of data transferred per each page view. 70% of the users only read the first screen and hence pictures outside the first screen don't need to be downloaded before the user starts to scroll the page. This is to reduce server-side cost. Current Solution and It's Drawbacks The current solution pretty much consists of three steps: 1. The server outputs s with @src pointing to a transparent image, transparent.gif, and with @data-src pointing to the real location of the image. 2. Listen to the window.onscroll event. 3. The event handler finds all s in the visible area and set their @src to @data-src that were stored. Some of the drawbacks of this approach: 1. "find all s in the viewable area" isn't easy. 2. If the above query requires boundingClientRect calls, it causes unnecessary layout and hence harms the performance. 3. Browsers can't use better strategies such as: 1. Download more pictures when reflow/repaint don't frequently happen. 2. The network/bandwidth is good and browsers can download more. 3. According to user setting, download pictures that are enough close to the visible area, say one or two screen height. Idea Bainstorming 1. the @defer attribute on and 2. the similar @deferpolicy attribute with value a combination of visible, network-idle and render-idle 3. a global switch as a http header or an attribute on html to switch UAs image loading from "obtain images immediately" to "obtain on demand" or vice versa. 4. onscrollintoview/onscrolloutofview events 5. DOMVisibilityChanged event The wiki page (Chinese) [1] contains some more description of the ideas. [1] http://www.w3.org/html/ig/zh/wiki/Proposals/img_lazyload Thanks Gray Zhang -- 张立理 GrayZhang 博客：http://www.otakustay.com 微博：http://www.weibo.com/otakustay 邮箱：otakus...@gmail.com
